Bug 56032 - WebSocket Endpoint onClose method not called when channel closed by thread interruption
WebSocket Endpoint onClose method not called when channel closed by thread in...
Status: RESOLVED FIXED
Product: Tomcat 8
Classification: Unclassified
Component: WebSocket
8.0.x-trunk
All All
: P2 normal (vote)
: ----
Assigned To: Tomcat Developers Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-01-19 10:56 UTC by Kenneth Gendron
Modified: 2014-01-21 19:54 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Gendron 2014-01-19 10:56:23 UTC
When an interrupted thread uses the basic or asynchronous remote of a session to write, the underlying channel is closed (this is as expected); however, the onClose method of the associated endpoint is not called.  This can lead the server into believing the session is still active.  The only way I have gotten around it is to delegate the write methods to6 a thread that can't possibly be interrupted.
Comment 1 Mark Thomas 2014-01-20 20:59:35 UTC
Do you have some unit tests or some sample code to demonstrate the problem?
Comment 2 Mark Thomas 2014-01-20 21:49:50 UTC
I've been looking at the WebSocket code and (by tweaking a unit tests an using a few break points) I can create a situation where the server times out trying to write a WebSocket message to the client. The behavior in this case should be the same as if the thread waiting for the write to complete was interrupted.

I see the onError() call to the Endpoint but the connection is not closed. That does not seem right to me. Generally any call to onError() should be followed by the closure of the session unless we are sure that the situation is recoverable (and the nature of the protocol is that it almost certainly is not recoverable).

There are a few things I still want to check but I should be in a position to apply the fix for this tomorrow.
Comment 3 Kenneth Gendron 2014-01-21 19:25:50 UTC
Thank you very much.
Comment 4 Mark Thomas 2014-01-21 19:54:34 UTC
This has been fixed in 8.0.x for 8.0.0 onwards and in 7.0.x for 7.0.51 onwards.