https://bz.apache.org/bugzilla/show_bug.cgi?id=66508
Mark Thomas <ma...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEEDINFO |NEW
--- Comment #12 from Mark Thomas <ma...@apache.org> ---
OK. I can recreate this.
The sequence is:
- Thread 1: Executor or similar calls Session.getAsyncRemote().sendText()
- Thread 1: Acquires messagePartInProgress semaphore
- Thread 1: Gets as far as the call to OperateState.start()
- Client closes the connection. This triggers:
- The poller to fire a SocketEvent.ERROR
- The in-process write to fail
- Thread 2: Starts to process SocketEvent.ERROR
- Thread 2: is holding the SocketWrapper lock
- Thread 2: Thread 2 gets as far as sending the close message but has to wait
for the messagePartInProgress semaphore
- Thread 3: Starts to process the failure of the in-process write
- Thread 3: failed() method called for write completion handler
- Thread 3: SocketEvent.ERROR task send to executor
- Thread 4: Executor starts to process SocketEvent.ERROR task send by thread 3
- Thread 4: Blocked waiting to acquire the SocketWrapper lock
On one level, the issue is that the processing of SocketEvent.ERROR expects any
in-progress (and failed) message to have released the messagePartInProgress
semaphore. But that doesn't happen.
Looking more broadly, one could question if there is any benefit at all in
attempting to send a WebSocket close message after any form of IOException
rather than just closing the TCP connection.
Note, the previous fix addressed a similar issue where Thread 1 was sending a
message in response to a received message.
I intend to try and fix this in the SocketEvent.ERROR handling. The higher
level discussion is something probably better suited to the dev@ list. If I
can't fix this in SocketEvent.ERROR then we may need to return to the high
level discussion.
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
