DO NOT REPLY [Bug 17094] New: - multi-threading problem

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17094>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17094

multi-threading problem

           Summary: multi-threading problem
           Product: Tomcat 3
           Version: 3.3.1 Final
          Platform: Sun
        OS/Version: Other
            Status: NEW
          Severity: Major
          Priority: Other
         Component: Webapps
        AssignedTo: tomcat-dev@jakarta.apache.org
        ReportedBy: yying21@hotmail.com


While using tomcat 3.3.1 for our company, I found a multi-threading problem in 
the session management code.

Here is HttpSessionFacade.java invalidate() method:

1)  public void invalidate() {
2)	checkValid();
3) 	realSession.getTimeStamp().setValid( false );
4)	// remove all attributes
5)	if( dL > 0 ) d("Invalidate " + realSession.getId());
6)	realSession.setState(ServerSession.STATE_EXPIRED);
7)	realSession.recycle();
8)    }

Line 6 invokes a list of call back functions.  One of them put the session 
object at the end of the recycled buffer, which contains a list of old session 
objects that can be used when the next time a new session is created.  

Line 7 clears and recycles attributes inside the session object.  

Here is a scenerio where tomcat will have a problem.

Thread1 invalidates session A

Thread2 starts a new session B

Thread3 continues using session B

--
At t1, Thread1 runs upto Line 6, the session object gets put into the recycled 
buffer.

At t2, Thread2 initiated a new request that is not associated with any session, 
so the session management code creates a new session object.  The first thing 
tomcat does is to retrieve a session object from the end of the recycled 
buffer.  Now Thread2 has the same object that Thread1 is using, but with new 
session Id.  When a session gets created, a list of call back functions get 
called and a new session id generated.

At t3, Thread1 continues to run, when it runs to line 7, it invalids TimeStamp 
object and id object inside the session object.  The implementation for 
ServerSession's isValid() method is the following

public boolean isValid() {
	return getTimeStamp().isValid();
    }

At t4, Thread3 starts a request, with the same session id the same as thread 
1.  This session id is passed in by the cookie.  This session should be valid.  
But the session management code thinks the session object is invalid since the 
TimeStamp object inside the session is invalidated by Thread1.

Basically, tomcat code is recyling the session object too early, before the 
code is completely done with the session object.

I also looked at Tomcat 4.1 code, it seems Tomcat4.1 addressed this problem 
already.

YaJie

---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org