tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <wbar...@wilshire.com>
Subject Re: [Tomcat 3.3rc1 and 3.3rc2] Same SessionID delivered to many
Date Thu, 11 Oct 2001 23:43:31 GMT
I'm not as thorough as Bojan, but using openssl as the client, and a jsp
page that sleeps for five seconds (to simulate load), I also can't reproduce
this.  I started three clients one second apart, and each client makes five
requests (using HTTP/1.1 Keep-Alive).  The result is fifteen different
session ids.

Proxy servers can cause things like this if the servlet isn't careful, but I
can't see why a proxy would go to the trouble of re-validating the request
with the server and then simply send the cached page.
----- Original Message -----
From: "Bojan Smojver" <bojan@binarix.com>
To: <tomcat-dev@jakarta.apache.org>
Sent: Thursday, October 11, 2001 4:29 PM
Subject: Re: [Tomcat 3.3rc1 and 3.3rc2] Same SessionID delivered to many


> Hans Schmid wrote:
> >
> > Thanks Ignacio,
> >
> > yes, we use mod_ssl but the problem in our setup is, that we have
> > Tomcat3.3 for all new developed modules of our application running in
> > parallel with
> > JServ for our legacy modules. So we still have to use mod_jserv
> > in production :(
> >
> > We expect a load up to 500 concurrent sessions in peek hours during the
> > next couple of months, so we plan to buy a hardware SSL solution anyway.
> >
> > Is there a solution in sight that would deal with this scenario.
> > We have to use Cookies in our old modules anyways but would like to
> > get away from it. (this was one argument for our move to Tomcat :)
> >
> > Thanks anyway,
> > keep up the excelent work,
> > Hans Schmid
> >
> > einsurance Agency AG
> > Information Technology
> > Bayerstra├če 33
> > 80335 M├╝nchen
> >
> > Tel: +49-89-55292- 860
> > Fax: +49-89-55292- 855
> >
> > eMail: Hans.Schmid@einsurance.de
> > http://www.einsurance.de
> >
> > A workaround for the useCookies under Apache+mod_ssl is to activate the
> > support for SSL in tomcat that is installing JSSE and uncommentting the
> > appopiate line in server.xml..
> >
> > Hope that help, is not nice but will make work noCookies sessions in
> > your config..
> >
> > Saludos ,
> > Ignacio J. Ortega
> >
> > > -----Mensaje original-----
> > > De: Hans Schmid [mailto:Hans.Schmid@einsurance.de]
> > > Enviado el: jueves 11 de octubre de 2001 17:21
> > > Para: Tomcat-Dev
> > > Asunto: [Tomcat 3.3rc1 and 3.3rc2] Same SessionID delivered to many
> > > clients during session creation ?
> > >
> > >
> > > Hi developers,
> > >
> > > 1.) First a note about an unanswered observation from the mailing list
> > > archive:
> > > we are experiencing exactly the same behaviour with Tomcat 3.3-rc1
> > > with mod_jk AJP1.3 Apache 1.3.19(Solaris 8 Sparc) when using SSL as
> > > described below.
> > > Thats why we had to changed to <SessionId cookiesFirst="true"
> > > noCookies="false" />
>
> This is from the tests I did with TC 3.3 RC2, mod_jk 1.2.0 (j-t-c),
> Apache 1.3.20, IBM JDK 1.3.0, RedHat Linux 7.0:
>
> ---------------------------------------------------------------
> <SessionId cookiesFirst="true" noCookies="false" />
>
> ab -c 10 -n 10000 -v 99 http://www.dev.dev/contact/inquiry.vm > ab.log
>
> grep jsessionid ab.log | wc -l
>   10005
>
> grep jsessionid ab.log | sort -u | wc -l
>   10005                                       <-- ie. all 10005 are
> unique
> ---------------------------------------------------------------
>
> Next test:
>
> ---------------------------------------------------------------
> <SessionId cookiesFirst="false" noCookies="true" />
>
> grep jsessionid ab.log | wc -l
>   10000
>
> grep jsessionid ab.log | sort -u | wc -l
>   10000                                      <-- ie. all 10000 are
> unique
> ---------------------------------------------------------------
>
> Then:
>
> ---------------------------------------------------------------
> <SessionId cookiesFirst="true" noCookies="true" />
>
> ab -c 10 -n 10000 -v 99 http://www.dev.dev/contact/inquiry.vm > ab.log
>
> grep jsessionid ab.log | wc -l
>   10007
>
> grep jsessionid ab.log | sort -u | wc -l
>   10007                                      <-- ie. all 10007 are
> unique
> ---------------------------------------------------------------
>
> And finally:
>
> ---------------------------------------------------------------
> <SessionId cookiesFirst="false" noCookies="false" />
>
> ab -c 10 -n 10000 -v 99 http://www.dev.dev/contact/inquiry.vm > ab.log
>
> grep jsessionid ab.log | wc -l
>   10001
>
> grep jsessionid ab.log | sort -u | wc -l
>   10001                                     <-- ie. all 10001 are unique
> ---------------------------------------------------------------
>
> This is what the beginning of the inquiry.vm looks like:
>
> ---------------------------------------------------------------
>   $res.encodeURL($req.getRequestURI())
>
>   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "DTD/xhtml1-tra
> <html xmlns="http://www.w3.org/1999/xhtml" lang="en"
> xml:lang="en"><head><tit
> ---------------------------------------------------------------
>
> Which translates in ab.log into (due to -v 99):
>
> ---------------------------------------------------------------
>   /contact/inquiry.vm;jsessionid=zmct7h73x4
>
>   <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
> "DTD/xhtml1-tra
> <html xmlns="http://www.w3.org/1999/xhtml" lang="en"
> xml:lang="en"><head><tit
> ---------------------------------------------------------------
>
> Do you have any more pointers on how to replicate this problem? I can't
> seem to be able replicate it...
>
> Bojan
>
>


*----*

This message is intended only for the use of the person(s) listed above 
as the intended recipient(s), and may contain information that is 
PRIVILEGED and CONFIDENTIAL.  If you are not an intended recipient, 
you may not read, copy, or distribute this message or any attachment.  
If you received this communication in error, please notify us immediately 
by e-mail and then delete all copies of this message and any attachments.


In addition you should be aware that ordinary (unencrypted) e-mail sent 
through the Internet is not secure. Do not send confidential or sensitive 
information, such as social security numbers, account numbers, personal 
identification numbers and passwords, to us via ordinary (unencrypted) 
e-mail. 

Mime
View raw message