https://issues.apache.org/bugzilla/show_bug.cgi?id=55267
--- Comment #3 from Mark Thomas <ma...@apache.org> --- Thanks for the thread dump. I'm going to assume that other information provided elsewhere is unchanged. i.e. the thread is not stuck but configured to use an excessively long timeout of 30 minutes. I have not been able to recreate this issue - even with a debugger - but I think I have got close enough to figure out what is going on and I believe I have a solution. I believe the following is happening: - Atmosphere is setting a 30 minute timeout for Comet connections - That timeout is used to set the socket read/write timeout - When the client disconnects Atmosphere closes the comet event - That triggers a write to the socket and at this point the timeout is still 30 mins - Something about the exact timing and state means that an exception is not thrown One could argue several root causes: 1 Tomcat should only apply the Comet timeout to reads, not writes 2 Atomsphere should reset the timeout once an error occurs 3 Tomcat should reset the timeout once an error occurs 4 Tomcat should reset the timeout as soon as close is called on the comet event We might be able to do something about 1 but 3 and/or 4 look like simpler solutions. Looking at implementing a solution is next on my TODO list. -- 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
