Did some load test and thread got stuck, see dump. Basically I just simulate 100 users that connect and disconnect.
There is no thread dump attached to this issue. The bug will get resolved as INVALID without one.
Created attachment 30595 [details] dump
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.
Great - waiting for the fix (I'm trying to figure out this issue for months, but it's indeed very hard to replicate locally.)
I believe I have fixed this in trunk. In the end, option 1 was simpler to implement. You'll need to build from svn to test this. Let us know how you get on. If you still see the problem, feel free to re-open this issue.
Great - quick question - can I build and use the tomcat on prod? or do I need to do some optimizations to use the trunk version on prod?