DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
------- Additional Comments From [EMAIL PROTECTED] 2005-10-12 14:09 -------
(In reply to comment #4)
> 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
> 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?
The whole idea of even checking for duplicates is a nonsense (beyond giving
people some sense of safety). If the id generation has conflicts, then it means
the system is completely insecure, so fixing a bug which will never actually
occur doesn't have any benefits.
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]