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=36995>. 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=36995 Summary: duplicate session ids Product: Tomcat 4 Version: 4.1.31 Platform: PC OS/Version: other Status: NEW Severity: normal Priority: P2 Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: [EMAIL PROTECTED] Greetings, We ran a simple load test against Tomcat 4.1.x after having some strange session effects on our website, to see if the generated session ids are really unique. The test made HTTP requests with wget, extracted the newly generated session ids and wrote them into a file. It turned up two pairs of duplicate session ids from active sessions. I read the source code to see how the session ids are generated, and found this code in org.apache.catalina.session.ManagerBase#createSession() from Tomcat 4.1.31, line 544 to 555: synchronized (sessions) { while (sessions.get(sessionId) != null){ // Guarantee uniqueness sessionId = generateSessionId(); duplicates++; // @todo Move appending of jvmRoute generateSessionId()??? if (jvmRoute != null) { sessionId += '.' + jvmRoute; } } } session.setId(sessionId); I came up with the following scenario, where duplicate session ids could be generated: Thread 1 runs into the method, generates a session id, checks if the session id is unique and leaves the synchronized block. There the thread 1 pauses and thread 2, a request from a different user, takes over. Thread 2 runs into the method, generates the same session id by pure chance and checks if the session id is unique. Since thread 1 has not yet called setId, the session id isn't stored in the HashMap, the session id is considered unique and the loop is left. The method setId() is called, which results in a call to the method add() of the ManageBase class. There the new session object is stored in the HashMap with the session id. Thread 1 continues and calls setId() as well, overwriting the already present session object in the HashMap with a new one. Both threads continue and return a duplicate session id to different user. Both users use the same session object for subsequent requests. I know the chances for this scenario are slim, as it must generate the same session id and run into the race condition between the two syncronised blocks in createSession() and add(), but it appears to be happening. Shouldn't the check for uniqueness and the adding of the newly generated session id be in the same syncronized block of "sessions", to really ensure uniqueness? Or did I get something wrong here? Tomcat 5.0.28 and Tomcat 5.5.9 appears to have the same problem, btw. Thanks, Christian -- 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]
