-
-
Notifications
You must be signed in to change notification settings - Fork 595
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Intermittent long delay during connection upgrade #393
Comments
Out of curiosity, can you retest this after adding a short delay before you send the
|
Thanks for the very fast response! I have tried your suggestion and unfortunately the problem still occurs. I've attached new client and server logs with this in place - see below. bad-with-join-delay-client.log Strangely, the server doesn't even seem to acknowledge the room join request sent at 16:03:47: Client
Server
Furthermore, after we've managed to recover, the server repeatedly logs that it can't send future messages to the session that was already closed:
|
Unfortunately the logs do not give me any clues. For some reason the client appears to be waiting for something during those 30 seconds, and I don't know what that is. If you think you can build a small example app that can reproduce this issue that would be useful. I'm going to try to do this myself too, based on the code you posted. |
Seems related to this => miguelgrinberg/python-engineio#160 (comment) (I think this logic is missing in python-engineio from the javascript version: https://github.com/socketio/engine.io/blob/cb0ac6fddcad12c454651bf0e1a312a154e228a4/lib/transports/polling.js#L112-L117) |
I believe this is addressed by miguelgrinberg/python-engineio@f2cce2b. |
Summary
We are using
python-socketio
to push out regular service status updates to browser clients, which are using thesocket.io
JS client library. Most of the time it works fine but we are intermittently seeing a situation where there is a ~30 second delay part-way through the connection upgrade process, and no messages are received during this time. Eventually the connection is closed (although the process looks a bit messy) and a reconnect occurs, after which everything works fine again.We can reproduce this fairly easily with a unit test that repeatedly navigates to the relevant page and away again, forcing the socket to be recreated and a connection re-established each time. We reliably run into the issue after a few iterations of this.
Versions
python-socketio
: 4.3.1 (have also tried 4.4.0)python-engineio
: 3.10.0 (have also tried 3.11.0)socket.io JS client
: 2.3.0 (have also tried 2.2.0)Code
This is a simplified version of our server code, which is running inside a Docker container within a Kubernetes pod:
The relevant bit of our client code is:
Logs
I've captured some detailed logs of both client and server both when the connection works and when it doesn't (see attached).
bad-client.log
bad-server.log
good-client.log
good-server.log
When the issue occurs, the client log clearly shows the delay while it's probing for the availability of the websocket transport:
On the server side, we see part of the upgrade process and then it seems to stop (while still emitting update messages)...and eventually the server gives up and closes the socket:
As you can see in the full log, a re-connection follows and it works, but we really want to eliminate this 30 second delay as it leads to a bad user experience.
Workaround
As a test, we tried using the websocket transport directly instead of starting with long polling (as described at https://socket.io/docs/client-api/#With-websocket-transport-only):
This seems to solve the problem - our test case can go through hundreds of iterations without any problem.
The text was updated successfully, but these errors were encountered: