Is there anyway to disable the websocket closeTimeout? about ws HOT 9 CLOSED

Why is there a 30-second timer to emit the close event when the server knows the socket is closed on the client end and has the close code & reason?

Because a misbehaving client might keep the connection open indefinitely. When the connection is closed (correctly or forcibly) the timeout is cleared.

from ws.

Thanks for the response. The connection is closed properly on the client end. On the Server side, We are checking the readyState of the WebSocket before sending a message to it. The readyState of the WebSocket is 2. The server knows that it was closed and it has closeCode (_closeCode) as well. As I mentioned before, those connections will be there on the server for 30 seconds, even though they are in closing state, and the server will allocate resources for those lingering connections for that duration. Could you please suggest a solution to overcome this issue?

from ws.

The connection is closed properly on the client end. On the Server side, We are checking the readyState of the WebSocket before sending a message to it. The readyState of the WebSocket is 2. The server knows that it was closed and it has closeCode (_closeCode) as well.

It means the connection is not closed. The socket did not emit the 'close' event, otherwise the timeout is cleared. See

from ws.

Thanks for the clarification. May I know why there is a delay in emitting the close event when we clear the closeTimer while setting the readyState of the WebSocket to 2 on SocketOnClose function? Sometimes it took 3 seconds, 10 seconds, or even 30 seconds to emit the close event of the socket, which is in the closing state.

from ws.

The 'close' event on the websocket is emitted after the 'close' event is emitted on the underlying socket and after all buffered data is read.

from ws.

• Please correct me if I am mistaken, I believe that receiverOnConclude is the method that will be invoked first, providing the closeCode and reason when the client closes the WebSocket connection.
• Could we please consider performing the cleanup tasks there and terminating the underlying socket (which is in closing state), thereby emitting the close event right away?
• Do we need to wait until the buffered data is read, and would terminating the socket in the receiverOnConclude method cause any issues?
• We frequently encounter situations where multiple sockets linger in the closing state for over 10 seconds, sometimes up to 30 seconds as mentioned earlier.
• It would be beneficial if the server could promptly identify when a socket enters this closing state, close the underlying connection, and emit the close event accordingly.
• These lingering 'zombie' connections unnecessarily consume server resources, which could potentially impact the performance of the server.

from ws.

Please correct me if I am mistaken, I believe that receiverOnConclude is the method that will be invoked first, providing the closeCode and reason when the client closes the WebSocket connection

That is only one part of the closing handshake. It means a peer received the close frame. The connection can be closed only when a peer has both sent and received a close frame.

Could we please consider performing the cleanup tasks there and terminating the underlying socket (which is in closing state), thereby emitting the close event right away?

You can use websocket.terminate() to do that but the connection is abruptly closed without completing the closing handshake.

Do we need to wait until the buffered data is read, and would terminating the socket in the receiverOnConclude method cause any issues?

All buffered data is read regardlessly, but you have no guaranteed that the close handshake completes correctly if you destroy the socket.

We frequently encounter situations where multiple sockets linger in the closing state for over 10 seconds, sometimes up to 30 seconds as mentioned earlier.

You should monitor the 'close' event of the underlying socket. Check if that is emitted correctly.

It would be beneficial if the server could promptly identify when a socket enters this closing state, close the underlying connection, and emit the close event accordingly

It does, that's why the close timer exists. If the connection is not closed correctly in a reasonable amount of time, it is forcibly closed.

These lingering 'zombie' connections unnecessarily consume server resources, which could potentially impact the performance of the server.

That is probably a network / overload system issue.

from ws.

See

from ws.

I'm closing this as answered.

from ws.