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: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
