-
Notifications
You must be signed in to change notification settings - Fork 10.1k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
WebSocket CLOSE_WAIT on disconnect #83
Comments
I absolutely agree. This drives me nuts, can't release my project because of that. |
Has this issue been fixed yet? I too am facing this problem and there are lots of connections in our env hanging on CLOSE_WAIT. To remove them, we don't have any option other than restarting the server again. I tried workaround mentioned by Rick but still no luck. Can someone help in here as we don't want to keep re-starting out server periodically due to CLOSE_WAIT connections exceeding max file descriptors? I have already increased file descriptor limit and don't want to increase it more. Anyways even after doing so, still issue will remain. |
Well, I updated to node v0.3.6 and the latest socket.io which works fine |
thanks Sascha for such a quick reply :) I have updated socket.io. Let me try updating node as well and will then update this thread with my findings so as to let all know. |
If I open a bunch of WebSocket connections and then drop them, they stay in the CLOSE_WAIT state, which uses up a file descriptor until a timeout (a few minutes). This means you can pretty quickly hit max file descriptors (typically set to 1024 or 4096) if you've got a lot of people connecting and disconnecting. One can use lsof or netstat to see all the open file descriptors in CLOSE_WAIT state. A fix in the websocket.js code is to destroy the connection after receiving the end event:
This seems to solve the problem.
The text was updated successfully, but these errors were encountered: