Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: domain of lists@nabble.com designates
 72.21.53.35 as permitted sender)
Message-ID: <8097754.post@talk.nabble.com>
Date: Sat, 30 Dec 2006 04:47:35 -0800 (PST)
From: Peter Coppens <pc.subscriptions@gmail.com>
To: users@tomcat.apache.org
Subject: Re: session#getId changes during doGet invocation under heavy load
In-Reply-To: <BAY133-DAV462E6BE50EA35B7CB0F27AEC60@phx.gbl>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
References: <8081064.post@talk.nabble.com>
 <AEF3D568DD1D9E428048C592AA1645970543D10F@USRV-EXCH4.na.uis.unisys.com>
 <8085181.post@talk.nabble.com>
 <327858f40612290331y3a357d02h897f42eb5bda4b85@mail.gmail.com>
 <BAY133-DAV462E6BE50EA35B7CB0F27AEC60@phx.gbl>


I am gathering more evidence that this is related to a session expiring on
one hand and a request being processed for that same session.

I have been debugging the tomcat code a bit, and I have the *impression*
that the expiration handling is not thread safe. It seems possible at first
sight that the background processor decides a session is expired while at
the same time another thread starts a request for that same session.

I will try to debug a bit more and if I find more I will let you know.

Thanks,

Peter

PS What does "O/T" mean ?


Martin Gainty wrote:
>=20
> Agreed
> Once you have your use cases and test cases identified
>=20
> If you want the server to maintain its own side of the relationship
> independent of client activity then you should consider container managed
> persistence
> More info avaialable at
> http://www.javaworld.com/javaworld/jw-08-2006/jw-0828-persistence.html?pa=
ge=3D6
>=20
> Feel free to contact me offline as this is definitely O/T
> Martin--
> -------------------------------------------------------------------------=
--=20
> This e-mail message (including attachments, if any) is intended for the
> use of the individual or entity to which it is addressed and may contain
> information that is privileged, proprietary , confidential and exempt fro=
m
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.
> -------------------------------------------------------------------------=
--=20
> Le pr=C3=A9sent message =C3=A9lectronique (y compris les pi=C3=A8ces qui =
y sont annex=C3=A9es,
> le cas =C3=A9ch=C3=A9ant) s'adresse au destinataire indiqu=C3=A9 et peut =
contenir des
> renseignements de caract=C3=A8re priv=C3=A9 ou confidentiel. Si vous n'=
=C3=AAtes pas le
> destinataire de ce document, nous vous signalons qu'il est strictement
> interdit de le diffuser, de le distribuer ou de le reproduire.
> ----- Original Message -----=20
> From: "Leon Rosenberg" <rosenberg.leon@googlemail.com>
> To: "Tomcat Users List" <users@tomcat.apache.org>
> Sent: Friday, December 29, 2006 6:31 AM
> Subject: Re: session#getId changes during doGet invocation under heavy
> load
>=20
>=20
>> Do I understand it right, that you made it a reproduceable testcase?
>> If so, can we have a look on it?
>>=20
>> thank you
>> Leon
>>=20
>> On 12/29/06, Peter Coppens <pc.subscriptions@gmail.com> wrote:
>>>
>>> Thanks Chuck.
>>>
>>> I have done some further research and I have the impression that there
>>> is
>>> some kind of race condition where a session that is being removed
>>> because of
>>> a timeout is also handling requests.
>>>
>>> The loggings indicate that a session is destroyed but then nevertheless
>>> a
>>> doGet is invoked with a request parameter that refers to that timed out
>>> session.
>>>
>>> If I crank up the timeout, seriously reducing the chances a session
>>> times
>>> out before it has completed all the client requests it is supposed to
>>> handle
>>> during the test, the problem does no longer occur.
>>>
>>> I am not sure where that leaves me. I am still uncertain as to what the
>>> servlet is doing wrong.
>>>
>>> Would you (or anyone else) have any other comments on this?
>>>
>>> Thanks,
>>>
>>> Peter
>>>
>>>
>>>
>>> Caldarale, Charles R wrote:
>>> >
>>> >> From: Peter Coppens [mailto:pc.subscriptions@gmail.com]
>>> >> Subject: session#getId changes during doGet invocation under
>>> >> heavy load
>>> >>
>>> >> THe problem I run into is that, under heavy load, during the
>>> >> doGet invocation for the login request the session attached
>>> >> to the request is changed by some other thread (the value
>>> >> returned from getId changes and attributes that are originally
>>> >> set are removed).
>>> >
>>> > This is most likely an application problem - storing session- or
>>> > request-specific data in an inappropriately scoped structure (e.g., a
>>> > servlet field).  Under light load, this won't hurt, since the
>>> insertion
>>> > and retrieval for a given request don't overlap any other requests.=
=20
>>> As
>>> > the load increases, so does the probability of an overlap and
>>> erroneous
>>> > retrieval of data for another request.
>>> >
>>> >  - Chuck
>>> >
>>> >
>>> > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE
>>> PROPRIETARY
>>> > MATERIAL and is thus for use only by the intended recipient. If you
>>> > received this in error, please contact the sender and delete the
>>> e-mail
>>> > and its attachments from all computers.
>>> >
>>> > ---------------------------------------------------------------------
>>> > To start a new topic, e-mail: users@tomcat.apache.org
>>> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> > For additional commands, e-mail: users-help@tomcat.apache.org
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/session-getId-changes-during-doGet-invocation-und=
er-heavy-load-tf2892448.html#a8085181
>>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@tomcat.apache.org
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>>
>>=20
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@tomcat.apache.org
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>=20
>>
>=20

--=20
View this message in context: http://www.nabble.com/session-getId-changes-d=
uring-doGet-invocation-under-heavy-load-tf2892448.html#a8097754
Sent from the Tomcat - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org