This is a proof of concept application to prove that Heroku cannot handle socket.io polling transports while using Node clusters. (I thought it would not work, but turns our that it did work....)
The problem is that all the "sticky session" solutions have all of the workers using a random port on their server.listen(), and Heroku blocks all ports aside from process.env.PORT.
The source code was originally built here: https://github.com/ANURAGVASI/socket.io-multiserver-chatApp Accompanying blog article: https://blog.imaginea.com/7597-2/
Summary of the issue:
- For any heroku app that has at least 1 2x Dyno, two+ workers will be created (this can be simulated by creating two socket)
- Override the
WEB_CONCURRENCYenvironment variable to3or higher to allow workers on any dyno size
- Override the
- Because socket.io uses many http requests for a handshake or long polling transport, the same worker must handle all requests
- Note: this library has set the transport to
['polling']to force the simulation of browsers or networks without websocket support
- Note: this library has set the transport to
You can run this locally to confirm it is working
npm run build
npm start