DO NOT REPLY [Bug 34227] New: - Simultanenous HttpRequests with shared HttpSession can leave it unable to timeout

[bu...@apache.org]

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: evl123@yahoo.com


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: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org