Socket client emits messages, but doesn't receive anything from the server.

[gkaradzhov]

It's a weird issue, and I have spent 10s of hours at this point to try to debug it. Hoping for some guidance on what should I do next.

I have a web server with the following setup (deployed on Heroku for what is worth):
web: gunicorn -k eventlet app:app

socketio = flask_socketio.SocketIO(app, async_mode='eventlet', logger=True,
                                   engineio_logger=True, always_connect=True)

Then my client is set as follows:
var socket = io.connect('https://' + document.domain, {autoConnect: true, transports: ["websocket", "polling"], upgrade: true, forceNew:true});

I am developing a chat application where multiple clients connect to the same room and perform certain actions and chat with each other. Each action is recorded at server side. Running the application, everything seems to be kind of working - everything is connecting, no errors on client or server side. Everything that is emitted from the client side is received at the server.

The problem is that in about 25-50% of the cases, the client is not receiving emitted messages from the server. I can't find out why is it happening, the socket looks connected (it fired the 'connect' even) and is sending information correctly. That said, there is nothing I can do to fix that.

I am suspecting a couple of things, but I am not sure how to debug them:

1. Is the async mode correct, and maybe there is some other threading introduced somewhere by default?
2. It is trying to reuse connections from some sort of connection pool and it fails for some reason?

Any idea what to try, and how to debug?

[miguelgrinberg]

Not sure if this contributes to the problem or not, but your gunicorn command should also have -w 1 to limit to a single worker. Multiple workers are not supported when gunicorn does the load balancing between them.

Are your clients reconnecting? Any signs in the log of issues?

[gkaradzhov]

I think that was it...

The default parameter for gunicorn is 1, BUT it first looks into WEB_CONCURRENCY env var and takes that number instead.

And heroku sets it (somewhat unexplicitly) to 2:

~ $ echo $WEB_CONCURRENCY
2

I spent close to 40 hours on this, and you probably saved me just about as much! Cheers mate!