Re: Session-expiry bug? getLastAccessedTime
Hi, I debugged thru Tomcat3.2.1 source code this morning and it too has the same problem: Session.access() is called only once per request, before the request is processed (called by findSession in StandardManager) This would mean that getLastAccessedTime() always gives the time of (last-1) request. And the session-expiry thread looks at the wrong-time. IF getLastAccessedTime() should return the time of (last-1) request, then perhaps there should be another method getAccessedTime() that returns thisAccessedTime in StandardSession and this would be used by the session-expiry thread? Waiting to hear your responses, Thanks, Murthy -- This was discussed by the expert group for servlet 2.3, and Kief's understanding is what we came up with. In addition, that is what Section 7.6 says in 2.3 PFD (emphasis is added): The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed BEFORE the current request. Other subtleties: * The access time should be updated at the beginning of the request, rather than the end. * The session is considered "accessed" when the container recognizes that the request is part of a valid session, even if the application never calls request.getSession() on that particular request. It doesn't look like we're doing this in Catalina 4.0, or am I missing something? Session.access() only seems to be called when request.getSession() is called. Also, if the access time is updated at the beginning of the request, what should getLastAccessedTime() return? Let's say at the beginning of the request, the access() method is called, and does: this.lastAccessedTime = this.thisAccessedTime; this.thisAccessedTime = System.currentTimeMillis(); Fine. But what happens after the request is complete, and the session expiration thread calls getLastAccessedTime() to compare it against maxInactiveInterval, it will be using the time of the request before the most recent request. So if request B comes in 20 minutes after request A, the container will expire the session 10 minutes after the most recent request (assuming default values), since getLastAccessedTime() will return the time that request A happened. What am I missing? Kief _ http://www.TeamOn.com Transform Your E-mail into an Online Office - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session-expiry bug? getLastAccessedTime
Craig R. McClanahan typed the following on 12:52 PM 2/10/2001 -0800 This was discussed by the expert group for servlet 2.3, and Kief's understanding is what we came up with. In addition, that is what Section 7.6 says in 2.3 PFD (emphasis is added): The getLastAccessedTime method of the HttpSession interface allows a servlet to determine the last time the session was accessed BEFORE the current request. Other subtleties: * The access time should be updated at the beginning of the request, rather than the end. * The session is considered "accessed" when the container recognizes that the request is part of a valid session, even if the application never calls request.getSession() on that particular request. It doesn't look like we're doing this in Catalina 4.0, or am I missing something? Session.access() only seems to be called when request.getSession() is called. Also, if the access time is updated at the beginning of the request, what should getLastAccessedTime() return? Let's say at the beginning of the request, the access() method is called, and does: this.lastAccessedTime = this.thisAccessedTime; this.thisAccessedTime = System.currentTimeMillis(); Fine. But what happens after the request is complete, and the session expiration thread calls getLastAccessedTime() to compare it against maxInactiveInterval, it will be using the time of the request before the most recent request. So if request B comes in 20 minutes after request A, the container will expire the session 10 minutes after the most recent request (assuming default values), since getLastAccessedTime() will return the time that request A happened. What am I missing? Kief - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: Session-expiry bug? getLastAccessedTime
Thanks for the replies. I epxerimented with this by
1. keeping the timeout to 4 minutes
2. accessing the server 2-1/2 minutes after the start
3. Accessing it again after 2-1/2 more minutes,
but my session expired by then.
After a request is finished, lastAccessedTime should be
updated to = thisAccessTime, so getLastAccessedTime()
will return the time of the last request when
checked by the expiration code. Is this not the case?
I will debug into this to see if this is happening.
I will let you know.. thanks again,
murthy
--- Original Message ---
From: Craig R. McClanahan [EMAIL PROTECTED]
To: "[EMAIL PROTECTED]" [EMAIL PROTECTED]
Cc: "[EMAIL PROTECTED]" [EMAIL PROTECTED]
Subject: Re: Session-expiry bug? getLastAccessedTime
Date: Sat, 10 Feb 2001 12:52:24 -0800
Kief Morris wrote:
Murthy Gorty typed the following on 09:59 AM 2/9/2001 -0800
I noticed a problem with session timeouts in Tomcat3.2.1
The background thread that recycles sessions based on timeouts uses
Session.getLastAccessedTime().
The session object itself has two variables
lastAccessedTime and thisAccessedTime.
-
public long getLastAccessedTime()
{
return (this.lastAccessedTime);
}
lastAccessedTime is the time a request is made BEFORE the present request.
So, getLastAccessedTime is the time of the (last-1)request
and not the last request.
Isnt this a bug? shouldnt getLastAccessedTime return
thisAccesstime?
I haven't looked at this code in detail, but my thoughts on this are:
getLastAccessedTime() needs to return the (last - 1) during a request,
or it won't behave correctly for servlet code. After a request is finished,
lastAccessedTime should be updated to = thisAccessTime, so
getLastAccessedTime() will return the time of the last request when
checked by the expiration code. Is this not the case?
This was discussed by the expert group for servlet 2.3, and Kief's
understanding is what we came up with. In addition, that is what Section 7.6
says in 2.3 PFD (emphasis is added):
The getLastAccessedTime method of the HttpSession interface
allows a servlet to determine the last time the session was
accessed BEFORE the current request.
Other subtleties:
* The access time should be updated at the beginning of the request,
rather than the end.
* The session is considered "accessed" when the container recognizes
that the request is part of a valid session, even if the application never
calls request.getSession() on that particular request.
Kief
Craig
_
http://www.TeamOn.com Transform Your E-mail into an Online Office
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Session-expiry bug? getLastAccessedTime
Murthy Gorty typed the following on 09:59 AM 2/9/2001 -0800
I noticed a problem with session timeouts in Tomcat3.2.1
The background thread that recycles sessions based on timeouts uses
Session.getLastAccessedTime().
The session object itself has two variables
lastAccessedTime and thisAccessedTime.
-
public long getLastAccessedTime()
{
return (this.lastAccessedTime);
}
lastAccessedTime is the time a request is made BEFORE the present request.
So, getLastAccessedTime is the time of the (last-1)request
and not the last request.
Isnt this a bug? shouldnt getLastAccessedTime return
thisAccesstime?
I haven't looked at this code in detail, but my thoughts on this are:
getLastAccessedTime() needs to return the (last - 1) during a request,
or it won't behave correctly for servlet code. After a request is finished,
lastAccessedTime should be updated to = thisAccessTime, so
getLastAccessedTime() will return the time of the last request when
checked by the expiration code. Is this not the case?
Kief
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
Re: Session-expiry bug? getLastAccessedTime
Kief Morris wrote:
Murthy Gorty typed the following on 09:59 AM 2/9/2001 -0800
I noticed a problem with session timeouts in Tomcat3.2.1
The background thread that recycles sessions based on timeouts uses
Session.getLastAccessedTime().
The session object itself has two variables
lastAccessedTime and thisAccessedTime.
-
public long getLastAccessedTime()
{
return (this.lastAccessedTime);
}
lastAccessedTime is the time a request is made BEFORE the present request.
So, getLastAccessedTime is the time of the (last-1)request
and not the last request.
Isnt this a bug? shouldnt getLastAccessedTime return
thisAccesstime?
I haven't looked at this code in detail, but my thoughts on this are:
getLastAccessedTime() needs to return the (last - 1) during a request,
or it won't behave correctly for servlet code. After a request is finished,
lastAccessedTime should be updated to = thisAccessTime, so
getLastAccessedTime() will return the time of the last request when
checked by the expiration code. Is this not the case?
This was discussed by the expert group for servlet 2.3, and Kief's
understanding is what we came up with. In addition, that is what Section 7.6
says in 2.3 PFD (emphasis is added):
The getLastAccessedTime method of the HttpSession interface
allows a servlet to determine the last time the session was
accessed BEFORE the current request.
Other subtleties:
* The access time should be updated at the beginning of the request,
rather than the end.
* The session is considered "accessed" when the container recognizes
that the request is part of a valid session, even if the application never
calls request.getSession() on that particular request.
Kief
Craig
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
