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]>

Reply via email to