Unfortunately I have no repro yet. If I succeed in building one, I will most
certainly post it.

Thanks for all your help,

Peter


Leon Rosenberg-3 wrote:
> 
> 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 <[EMAIL PROTECTED]> 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:[EMAIL 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@tomcat.apache.org
>> > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > For additional commands, e-mail: [EMAIL 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@tomcat.apache.org
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
> 
> ---------------------------------------------------------------------
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/session-getId-changes-during-doGet-invocation-under-heavy-load-tf2892448.html#a8086761
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to