Received: from [198.76.25.3] (HELO nns.voyanttech.com) by voyanttech.com (CommuniGate Pro SMTP 3.4b3) with SMTP id 3436537 for [EMAIL PROTECTED]; Sun, 12 Jan 2003 16:04:42 -0700 Received: from exchange.sun.com (exchange.sun.com [192.18.33.10]) by nns.voyanttech.com (8.9.3+Sun/8.9.3) with SMTP id QAA08225 for <[EMAIL PROTECTED]>; Sun, 12 Jan 2003 16:52:44 -0500 (EST) Received: (qmail 25756 invoked by uid 97); 12 Jan 2003 23:05:56 -0000 Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm Precedence: bulk List-Unsubscribe: <mailto:[EMAIL PROTECTED]> List-Subscribe: <mailto:[EMAIL PROTECTED]> List-Help: <mailto:[EMAIL PROTECTED]> List-Post: <mailto:[EMAIL PROTECTED]> List-Id: "Tomcat Developers List" <tomcat-dev.jakarta.apache.org> Reply-To: "Tomcat Developers List" <[EMAIL PROTECTED]> Delivered-To: mailing list [EMAIL PROTECTED] Received: (qmail 25742 invoked by uid 98); 12 Jan 2003 23:05:55 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Content-Class: urn:content-classes:message X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Message-ID: <[EMAIL PROTECTED]> Date: Sun, 12 Jan 2003 16:03:35 -0700 From: "Phil Steitz" <[EMAIL PROTECTED]> User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020408 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tomcat Developers List" <[EMAIL PROTECTED]> Subject: Re: Duplicate session IDs are *common*[GFI-T105-3E21F8D3D7B6FFDE] References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <01cf01c2b9d6$f43cf250$[EMAIL PROTECTED]> <avr7o5$m1r$[EMAIL PROTECTED]> Content-Type: multipart/mixed; boundary="------------080606090209080902030004" X-OriginalArrivalTime: 12 Jan 2003 23:03:35.0647 (UTC) FILETIME=[D5E4F6F0:01C2BA8E] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
--------------080606090209080902030004 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 7bit Costin Manolache wrote: > > Could you make a small modification and run the same test with > 20 concurent threads ? I checked the code and we have plenty of > syncs, but you never know. OK -- for this I went to the horse's (or maybe I should say, "cat's") mouth with the same result -- collisions still look very unlikely. Here is what I did (using unpatched tomcat 4.1.18, Sun's linux JDK 1.3.1_03): 1. Put a jsp that does nothing but get a session and then invalidate it (sessionTest.jsp) in /webapps/examples; 2. Set up a jmeter test with 20 threads, no delay, hitting sessionTest.jsp 500 times each (SessionTest.jmx); 3. grep 'Created' localhost_examples_log.<date>.txt > sessions.txt; 4. Run "DispersionCheck.java" (attached) to grab the generated session IDs from sessions.txt and do the comparisons as before. Output is attached as DispersionCheckOut.txt. Note that among the 199,990,000 pairs of session ID's examined, none agreed in more than 13 of 32 hex digits. BTW, I noticed that in my original tests, I was only comparing the first half of the strings (forgot that the hex conversion doubles the length - DOH!). I have attached a corrected version of the standalone program DispersionCheck.java that does all of the comparisons and compares the distribution to B(32,1/16) instead of B(16,1/16). Results are as expected. -Phil > > I did check the code and it looks ok - plenty of synchronized() blocks. > But who knows ? If there is a problem, it could be "protection," not just synchronization (which just guarantees serialization). I notice that the valid flag is used to protect sessions from being updated while they are expiring, etc. I posted a (probably insignificant) bug report a couple of weeks ago (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15746) indicating that a session being recycled could in theory have attributes added by other threads still holding references to it between the time that its attributes are cleared and when its isValid flag is set to false. The result would be that a "dirty" session would be reused. I have been trying to make this (or other similar things) to happen using jmeter tests to no avail; but I will keep trying. > > Costin > > --------------080606090209080902030004 Content-Type: text/plain; name="SessionTest.jmx" Content-Transfer-Encoding: 7bit Content-Disposition: inline; FOR ANTI-VIRUS SECURITY, THIS EMAIL HAS BEEN REJECTED. REASON: THIS EMAIL CONTAINED AN ATTACHMENT TYPE OF '.jmx' WHICH IS NOT PERMITTED. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>