tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glenn Nielsen <gl...@mail.more.net>
Subject [PATCH] HttpSession handling
Date Tue, 20 Apr 2004 14:33:19 GMT
There are four Tomcat 4 bug reports filed on this problem.

There was one bug report filed for Tomcat 5 and Remy applied a
small patch to fix it.

Problems with expiring sessions have been reported numerous times.
The basic problem is as follows, starting at time 0 min and with
a max inactive interval of 30 minutes:

00 min: First request, new session created, LastAccessedTime 0
02 min: Second request, reuse session, LastAccessedTime 0
31 min: Third request, reuse session, LastAccessedTime now 2
33 min: Background manager thread expires session even though
        it has only been two minutes since the remote clients
        last request.

The argument for not changing how this works is based on how
the Servlet Spec defines Session.getLastAccessedTime().

But I agree with all those who have complained about this
behaviour that Tomcat session timeouts are buggy.

So I came up with a compromise that still allows the
HttpSession.getLastAccessedTime() to return the time of the
previous request to meet the servlet spec.
But internally sessions are expired when
current time > last request + max inactive interval.

When we do a major revision we should consider adding
the StandardSession.getLastUsedTime() method to the
org.apache.catalina.Session interface.

JDBCStore
---------

The JDBCStore required a great deal of unnecessary db
queries to manage the persisted data. This could severly
impact its ability to scale to large numbers of sessions.

1. When a JSESSIONID cookie was submitted with a request where
   the Session no longer exists multiple queries of the db occurred
   to try and load a persisted Session from the Store. I was
   seeing four attempts to load from the persistence store
   each request when a Session did not exist for a JSESSIONID.

   PersistentManagerBase swapIn() and swapOut() were patched
   to maintain a Hashtable of JSESSIONID's which do not exist
   in the Store so that they don't have to be checked multiple
   times.  Each checkInterval the Hashtable is cleared to
   prevent it from consuming too much memory.

2. The StoreBase.processExpires() method triggers a load of
   each Session persisted to the db each checkInterval to
   perform its test to determine if the Session has expired.
   This incurred alot of overhead on the db, especially
   if there was a large amount of session data. The number
   of queries performed each checkInterval is 1 + number of
   sessions persisted to the db + number of expired sessions
   removed.

   The StoreBase.processExpires() method was overridden
   in JDBCStore.  The method in JDBCStore performs a
   query of the db to find only those Sessions which should
   be expired. The number of queries performed here is 1 +
   2 * the number of expired sessions (load then remove
   of expired session).

3. JDBCStore.remove() is being called sometimes with a null
   sessionid String causing an unnecessary synchronization
   and db query.

   Added a check for a null sessionid String at top of method.

I propose that these patched be applied to Tomcat 4 first,
then to Tomcat 5.

Regards,

Glenn
On Fri, Jan 02, 2004 at 11:10:16AM +0200, Jarno.Peltoniemi@uta.fi wrote:
> Reading the servlet spec raised a couple of thoughts about http session
> handling to my mind. I did verify them, but did not file bug reports.
> 
> Should I write a patch for these?
> 
> 
> Thought #1
> ==
> 
> "SRV.7.6 Last Accessed Times
> The getLastAccessedTime method of the HttpSession interface allows a servlet
> to determine the last time the session was accessed before the current
> request. The session is considered to be accessed when a request that is part
> of the session is first handled by the servlet container."
> 
> Imagine the following situation with four requests in the same session:
> 
> Moment 0: Request #0 arrives. The session is initiated.
> Moment 1: Request #1 arrives. The request processing performs some long
> operation.
> Moment 2: Request #2 arrives.
> Moment 3: Request #3 arrives.
> Moment 4: The long operation of the request #1 processing is complete. Request
> #1 processing calls session.getLastAccessedTime(). According to the spec the
> method should return the time of moment 0 (request #0 was the previous
> request before the request #1). Tomcat returns the time of moment 2 (the time
> request #2 arrived) instead.
> 
> 
> Thought #2
> ==
> 
> If the session is created by the current request, the
> session.getLastAccessedTime() returns the session creation time. Should it
> return 0 instead? I'd find it a bit less incorrect.
> 
> 
> Thought #3
> ==
> 
> "SRV.7.5 Session Timeouts
> The session invalidation will not take effect until all servlets using that
> session have exited the service method."
> 
> Tomcat does nothing to ensure this.
> 
> To reproduce, set session timeout to 3mins and put the following code to
> service method:
> 
> HttpSession session = request.getSession();
> Thread.sleep(200 * 1000L); // a long operation =)
> session.getLastAccessedTime();
> 
> ->IllegalStateException is thrown
> 
> --
> Jarno Peltoniemi
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
----------------------------------------------------------------------
Glenn Nielsen             glenn@more.net | /* Spelin donut madder    |
MOREnet System Programming               |  * if iz ina coment.      |
Missouri Research and Education Network  |  */                       |
----------------------------------------------------------------------

Mime
View raw message