DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=34227>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34227 Summary: Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout Product: Tomcat 5 Version: 5.0.28 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] In the course of testing our web application have determined a race condition exists when simultaneous requests come in to tomcat sharing a session. The results are that a session will never timeout. Looking into the code and adding log entries, basically the StandardSession mantains an access count to determine how many threads are using the session at once. The counter is incremented at the beginning of the request and decremented during the recyle at the end if the session object is not null. The race condition must be that the shared session object becomes unavailable to recyle and therefore is left with a positive access count. The session monitor thread (in the StandardManager) uses the isValid to expire timed out sessions. But when a positive access count remains the session is always valid and therefore will never expire. We've also confirmed this behavior on 5.5.8. To see this effect, write a HttpSessionListener object for the web application and monitor session creation and destruction with a counter and using jmeter have a web page that has 2 javascript include tags calling each a servlet that uses the session for processing. Run up the jmeter on the server and then note the number of sessions that never expire, even though you can print out last access times that are far into the past. This is easier to see right away if you set session timeout to something low like a couple of minutes. If I get a chance to put more time into this I will followup with more and possibly have test files and scripts to highlight this. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
