https://bz.apache.org/bugzilla/show_bug.cgi?id=66574
--- Comment #6 from Mark Thomas <ma...@apache.org> --- This is related to one of the fixes for bug 66508. Specifically this change: https://github.com/apache/tomcat/commit/dccc2644ce701e88b152563473a350ec33a29a81 In short, the above change replaced the internal session state lock with the SocketWrapper lock. This removed the possibility of a deadlock caused by container and non-container threads obtaining the locks in different orders. Thread #824 is simulating blocking by calling Future.get() immediately after initiating the async action that created the Future. This thread is holding the SocketWrapper lock because it is a container thread responding to the receipt of a WebSocket message. Thread #844 is processing the async action initiated by thread #824. It is trying to close the WebSocket session. To do this it needs the SocketWrapper lock which is held by #824. Hence threads #824 and #844 are deadlocked. I have observed that simulating blocking often triggers deadlocks with Tomcat. This appears to be another instance of that but one where the locks participating in the deadlock are split across Tomcat and the application. I'm going to spend some time between now and the next round of releases looking at the way Tomcat uses locks - particularly in WebSocket - with a view to seeing if there is a different approach that is less susceptible to deadlock issues. -- 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
