-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[Bug] Manager leaks an EIO socket when disconnect is called right before connecting again #1014
Comments
benjamin-albert
added a commit
to benjamin-albert/socket.io-client
that referenced
this issue
Oct 24, 2016
darrachequesne
added a commit
that referenced
this issue
Nov 18, 2021
Previously, calling `socket.disconnect().connect()` could, if the connection was upgraded to WebSocket, result in "disconnect" being emitted twice, and an engine being leaked. Here's what happened: > socket.disconnect() - calls `socket.destroy()` so the socket doesn't listen to the manager events anymore - then calls `manager._close()` which closes the underlying engine but not the manager itself (it waits for the "close" event of the engine) > socket.connect() - calls `socket.subEvents()` so the socket does listen to the manager events - calls `manager.open()` which creates a new engine And then the first engine emits a "close" event, which is forwarded to the socket, hence the second "disconnect" event. Related: #1014
sunrise30
added a commit
to sunrise30/socket.io-client
that referenced
this issue
Jan 8, 2022
Previously, calling `socket.disconnect().connect()` could, if the connection was upgraded to WebSocket, result in "disconnect" being emitted twice, and an engine being leaked. Here's what happened: > socket.disconnect() - calls `socket.destroy()` so the socket doesn't listen to the manager events anymore - then calls `manager._close()` which closes the underlying engine but not the manager itself (it waits for the "close" event of the engine) > socket.connect() - calls `socket.subEvents()` so the socket does listen to the manager events - calls `manager.open()` which creates a new engine And then the first engine emits a "close" event, which is forwarded to the socket, hence the second "disconnect" event. Related: socketio/socket.io-client#1014
For future readers: This should be fixed by 99c2cb8, included in |
darrachequesne
added a commit
that referenced
this issue
Jun 6, 2022
Previously, calling `socket.disconnect().connect()` could, if the connection was upgraded to WebSocket, result in "disconnect" being emitted twice, and an engine being leaked. Here's what happened: > socket.disconnect() - calls `socket.destroy()` so the socket doesn't listen to the manager events anymore - then calls `manager._close()` which closes the underlying engine but not the manager itself (it waits for the "close" event of the engine) > socket.connect() - calls `socket.subEvents()` so the socket does listen to the manager events - calls `manager.open()` which creates a new engine And then the first engine emits a "close" event, which is forwarded to the socket, hence the second "disconnect" event. Related: #1014 Backported from 99c2cb8
darrachequesne
added a commit
that referenced
this issue
Jun 25, 2022
Previously, calling `socket.disconnect().connect()` could, if the connection was upgraded to WebSocket, result in "disconnect" being emitted twice, and an engine being leaked. Here's what happened: > socket.disconnect() - calls `socket.destroy()` so the socket doesn't listen to the manager events anymore - then calls `manager._close()` which closes the underlying engine but not the manager itself (it waits for the "close" event of the engine) > socket.connect() - calls `socket.subEvents()` so the socket does listen to the manager events - calls `manager.open()` which creates a new engine And then the first engine emits a "close" event, which is forwarded to the socket, hence the second "disconnect" event. Related: #1014 Backported from 99c2cb8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Steps to reproduce
server.js:
client.js:
Expected behavior
Node.js should exit after all clients have disconnected.
Actual behavior
Node.js freezes for about a second (before it tries to reconnect) and then it stays open forever (doesn't exit).
Workaround
I am aware that the proper way to do something like this is to first connect to the second namespace and then disconnect from the first namespace.
However I don't think something like this should leak an IEO socket.
Setup
Other information
See this commit in my fix_eio_leak branch which adds a failing test to
test/connection.js
Stay tuned for a pull request that fixes this bug.
The text was updated successfully, but these errors were encountered: