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 ------- Additional Comments From [EMAIL PROTECTED] 2005-10-11 14:02 ------- We have Suse 8.2 with kernel 2.4.20-64GB-SMP on our servers. Java version is 1.4.2_03 and Tomcat 4.1.29. As the chances for the described scenario are slim, I suggest to reduce the value of ManagerBase.SESSION_ID_BYTES from 16 to 2 or 3 for testing. This should increase the chances of duplicates returned by ManagerBase.generateSessionId() without affecting the behaviour of Tomcat. Additionally, I put a Thread.yield() below the end of the sychronized block in ManagerBase.createSession(), to provoke the racing time condition, further increasing the chances for the scenario. Then I started Tomcat with the JSP page "session.jsp": <%@ page language="java" %><%= request.getSession().getId() %> The test application performs repeated request from different threads, recoding the returned session ids and checking for duplicates. Even with the reduced random range it might take several runs to stumble into a duplicate. I'm sure there are better ways to test it, it is just a simple test. I'm not saying this is an urgent problem, or that it happens all the time, I merely think that it can happen, because random numbers, however large the range might be, are not unique by themselves, are they? And if it can happen, it will happen, eventually. Or am I missing something here? -- 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]
