Hmm...

I can see two senarios that can cause this situation:

1. Your sessions are configured to be waaaaayyyyy too short. I'd recommend at sessions live at least until the request times out.

2. You have a reference to the session in a servlet instance -- either directly or indirectly. Keep in mind that servlets are recycled between requests and should be entirely stateless. Class instance properties should be avoided. In this case an old session is continuously reused for several requests even after it's been invalidated.

Even if these two suggestions aren't an exact fit to your issue, maybe they can seed some ideas on what's going on.

--David

Peter Coppens wrote:

Actually it just seems to be related to the fact that under heavy load the db
connection starts to take longer than the timeout.
Apparently, a call to request.getSession() somewhere in the middel of the
doGet processing will also trigger invalidating the session, which is kind
of a nuisance as one should then apparently constantly check whether the
session has not expired during request processing.

I assume this is Servlet spec compliant, but it does seem to make my life
rather complex.

Would there be anyone having any suggestions to deal with this.
Thanks,

Peter


Leon Rosenberg-3 wrote:
On 12/30/06, Peter Coppens <[EMAIL PROTECTED]> wrote:
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.
The question is whether the next request get the "right" session again
or not. I had the impression from your first post, that this is the
case:
Request A - Session 1
Request B - Session 2 <-- which is wrong
Request C - Session 1 again.

I observed this behaviour 3 years ago on a resin 2.1.x, but had not
enough time to debug it.

regards
Leon
Thanks,

Peter

PS What does "O/T" mean ?
Off Topic

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" <[EMAIL PROTECTED]>
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


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#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: [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]






---------------------------------------------------------------------
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