Using Message bus in custom client on AWS. Need a little bit of help please :)

Firstly, I’m fully aware of the recommended Discourse setup but unfortunately it’s beyond my control at the moment.

On to the problem. My client had a custom React frontend built that is using Discourse as the backend app. I inherited the project in a bad state, and the previous developers had tried shoe-horning ActionCable into Discourse. Given that Discourse already uses Message bus for real-time features, I thought we should probably try and use that.

We were successful, locally. Message bus ‘just works’ and we were able to subscribe to all of the default Discourse message bus channels as well as create some of our own.

The problem we’re seeing is on our remote environments. We’re deploying to AWS EC2 instances that are behind an ALB and building the environment ourselves. I would have loved to go down the docker route, but the client just didn’t have the budget to spend time on changing things at this stage of the project :sadpanda:

The main symptom is that Message bug lags terribly. Nothing is really that real-time, but we know the message bus config is ok because it works great locally, so it must be something else.

I’m practically using the default Discourse nginx config as well. I initially thought this was the problem, as the message bus nginx config was missing, but after adding it in that doesn’t seem to have solved the issues we’re seeing.

After looking at the network tab in Chrome it’s clear there’s a problem because our /poll requests are waiting for 25 seconds and then downloading content for milliseconds. I know it should be the other way round, like it is when I’m running it locally or like it is on meta.

I’m aware this might also be an AWS ALB issue, but I’m literally clueless as to where to start. I was wondering whether @sam might have have any idea what the problem might be, or be able to point me in the right directions.

As always, any and all help is much appreciated!

We have message bus working with ALBs, in fact meta is is hosted on AWS.

My guess is that somewhere in your stack you have buffering on requests enabled which is causing them to be held for long periods of time.

It is most likely proxy_buffering in NGINX being set to on instead of off

1 Like

Hi @sam

Thanks for this suggestion. It seems to have fixed the issue in the network pane i.e. It does show content downloaded as 25s now and waiting as 35ms once the request has completed.

However, I was under the impression a message would be acted upon as soon as it’s received. Our app still seems to be waiting until the poll has finished before it actions any messages received.

We have long polling and chunked encoding enabled and as mentioned we’re using Discourse as our backend so would assume we don’t need to configure anything there.

Any ideas? Thanks