> From: Eric Waite [mailto:[EMAIL PROTECTED]
> Subject: Re: Sessionid duplication
>
> After adding entry I would expected to see the jvm1 appended
> to the end of the session id? I don't see it
It worked for me on 5.5.20:
http://myhost1.com:8080/servl
After adding entry I would expected to see the jvm1 appended to the end
of the session id?
I don't see it
- Eric
David Delbecq wrote:
according to code this will, for that engine, generate sessionid like this:
123456789ABCDEF0jvm1
En l'instant précis du 01/17/07 17:46, Eric Waite s'exp
according to code this will, for that engine, generate sessionid like this:
123456789ABCDEF0jvm1
En l'instant précis du 01/17/07 17:46, Eric Waite s'exprimait dans toute
sa noblesse:
> So using the following:
>
> with unique name and jvmRoute will ensure unique sessionIds?
>
> I apologize if th
So using the following:
with unique name and jvmRoute will ensure unique sessionIds?
I apologize if the question is naive, I am a novice in configuring Tomcat.
- Eric
Peter Crowther wrote:
From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
It's not quite that bad. If a jvmRoute is configur
> From: Caldarale, Charles R [mailto:[EMAIL PROTECTED]
> It's not quite that bad. If a jvmRoute is configured for the
> ,
> its value is appended to the randomly generated session id to make it
> unique across servers with a common front end.
That'd be sufficient - thanks, Chuck. I should read
En l'instant précis du 01/17/07 17:00, Peter Crowther s'exprimait dans
toute sa noblesse:
>> From: David Delbecq [mailto:[EMAIL PROTECTED]
>> Those are generated by taking the first 16 characters of
>> the md5 sum of a random byte[16].
>>
>
> Interesting. Note that although the existing code
> From: Peter Crowther [mailto:[EMAIL PROTECTED]
> Subject: RE: Sessionid duplication
>
> If you ever happen to get the same seed between two servers, you're
> seriously hosed - I *think* the way the code works, those systems will
> generate and continue to generate dupl
> From: David Delbecq [mailto:[EMAIL PROTECTED]
> Those are generated by taking the first 16 characters of
> the md5 sum of a random byte[16].
Interesting. Note that although the existing code makes considerable
effort to ensure this *is* random, a number of factors can apparently
decrease the r
Thank you for the great explanation.
- Eric
David Delbecq wrote:
By default, the manager generates 16 hexadecimal characters session
identifiers. Those are generated by taking the first 16 characters of
the md5 sum of a random byte[16]. If we assume (that might be a bit
wrong) that all md5 sums
By default, the manager generates 16 hexadecimal characters session
identifiers. Those are generated by taking the first 16 characters of
the md5 sum of a random byte[16]. If we assume (that might be a bit
wrong) that all md5 sums are equiprobables, that means in the end that
your session id is a 6
Very very small may be acceptable, what do you mean by very very small...?
Would 30,000 unique sessions across 3 servers have a potential issue?
Thanks.
Eric
Filip Hanik - Dev Lists wrote:
while there is a risk for duplicate sessions being generated, we
believe it to be very very small.
Wh
while there is a risk for duplicate sessions being generated, we believe
it to be very very small.
What you can do is set jvmRoute in the element to be unique for
each one, that makes it less likely to be duplicate.
Or you can come up with a better random algorithm, take a look at
org.apache.ca
12 matches
Mail list logo
