XHR Long Polling does not work properly with clustering

[wzrdtales]

First, how to replicate:
Start NodeBB as Cluster, deactivate WebSockets in your browser. In Firefox over about:config->websockets.enabled.
Version used: latest v.0.5.x (d6c17d5)

Open NodeBB in your Browser and test features.

Description of the issue:
If you need to fallback to XHR Long Polling e.g. using Cloudflare as not enterprise customer, several features are not working properly anymore.

1. The connection with XHR is very unstable.
2. Sometimes data gets delivered and sometimes you get just blank data.
3. If you try to install a plugin in admin panel it will never start installing this.
4. If you're chatting you've a very high latency, because of reconnecting the whole time.

I also made a test when websockets are enabled, if websockets are available everything is perferctly fine. It only occurs with XHR Long Polling.

Probable fix:
Implement optional chooseable Sticky Sessions.

Workaround for everyone with this problem:
Start multiple NodeBB instances on different ports or unix sockets and use nginx loadbalancing with ip_hash option to activate Sticky Sessions.

So far, thank you for this great software. I will take later a deeper look into it and may search for the root of this failure causing XHR to break on clustering.

[julianlam]

Thanks for the report @wzrdtales. Socket.IO (v0.9) should transparently drop down to xhr-polling when websockets are not available. If xhr-polling is not functioning properly, this is a potential problem.

That said:

• When using NodeBB with a cluster setup, always have a redis block set up in your config.json. NodeBB will look for a connection there in order to establish proper sticky-sessions for login and socket connections. Do this even if your primary data store is MongoDB.
• When using CloudFlare with NodeBB, as we do, switch off CF acceleration (grey clouds over orange), as they do not support websockets on all but the highest plans.

I look forward to hearing the results of your experiments 😄

[wzrdtales]

This is not the Problem, redis block is setup. And also Socket.IO drops down to xhr-polling, the problem is that this connection is not really stable and many features just do not work at all or deliver only sporadically data. The chat for example.

Also turning off acceleration is not an option in my case... So I need to fallback to XHR.

And I don't think this is a problem of Socket.IO itself, because sometimes It works and sometimes not. So there something within NodeBB is probably is going wrong in combination with XHR and clustering.

Also I have already tested a Socket.IO Server together with https://github.com/indutny/sticky-session. There were no problems with XHR.

I'm sorry, but I wont have any time today to make further debugging to help you find the failure. But I will look into this over the next days. At least I hope so.

[julianlam]

It's possible upgrading to socket.io 1.0 may resolve this.

[wzrdtales]

You could give this a try, but I'm not sure if Socket.IO is really the problem. I think I'ill take a look at this again at the weekend or if I find time at some of the next days. Till that my nginx workaround works fine, also if it's a bit ugly.

[julianlam]

Definitely. Again, thanks for reporting 👍 Maintaining xhr-polling compatibility is something we take seriously as well.

[barisusakli]

If you need to fallback to XHR Long Polling e.g. using Cloudflare as not enterprise customer, several features are not working properly anymore.

Well isn't this expected, if you are not on enterprise plan you can't use cloudflare with websockets. Also socket.io branch is merged to master now. You can give that a try.

[wzrdtales]

@barisusakli Well Cloudflare isn't the only situation where some may not be able to use Websockets. So yes surely I exepected this and I was aware of this Situation even before installing NodeBB, I have never said that I wondered about this fact. I just discovered XHR not working properly (even without Cloudflare and just WebSockets not available).

But this is why I opened this issue, instead of moving away from the Software, I reported the issue...

I tested the master branch now, and everything is working like a charm. Also it's a lot faster then before on establishing the connection to the Socket.IO server.