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:
>
> Agreed
> Once you have your use cases and test cases identified
>
> 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?page=6
>
> Feel free to contact me offline as this is definitely O/T
> Martin--
> ---------------------------------------------------------------------------
> 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 from
> disclosure. If you are not the intended recipient, you are notified that
> any dissemination, distribution or copying of this communication is
> strictly prohibited.
> ---------------------------------------------------------------------------
> Le présent message électronique (y compris les pièces qui y sont annexées,
> le cas échéant) s'adresse au destinataire indiqué et peut contenir des
> renseignements de caractère privé ou confidentiel. Si vous n'êtes 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 -----
> From: "Leon Rosenberg" <rosenberg.leon@(protected)>
> To: "Tomcat Users List" <users@(protected)>
> Sent: Friday, December 29, 2006 6:31 AM
> Subject: Re: session#getId changes during doGet invocation under heavy
> load
>
>
>> Do I understand it right, that you made it a reproduceable testcase?
>> If so, can we have a look on it?
>>
>> thank you
>> Leon
>>
>> On 12/29/06, Peter Coppens <pc.subscriptions@(protected):
>>>
>>> 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@(protected)]
>>> >> 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.
>>> 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@(protected)
>>> > To unsubscribe, e-mail: users-unsubscribe@(protected)
>>> > For additional commands, e-mail: users-help@(protected)
>>> >
>>> >
>>> >
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/session-getId-changes-during-doGet-invocation-under-heavy-load-tf2892448.html#a8085181
>>> Sent from the Tomcat - User mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To start a new topic, e-mail: users@(protected)
>>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>>> For additional commands, e-mail: users-help@(protected)
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To start a new topic, e-mail: users@(protected)
>> To unsubscribe, e-mail: users-unsubscribe@(protected)
>> For additional commands, e-mail: users-help@(protected)
>>
>>
>
--
Sent from the Tomcat - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
