Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (asf.osuosl.org: local policy)
content-class: urn:content-classes:message
Subject: Tomcat 5.0.28 session timeout / invalidation
Date: Mon, 7 Nov 2005 12:41:06 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C5E398.8555122A"
Message-ID: 
 <223E6519BDCAC74695BEE9D163F8E6590B9F2A@oakleaf10.oakleafconsultancy.com>
Thread-Topic: Tomcat 5.0.28 session timeout / invalidation
Thread-Index: AcXjmIUdpS1lmp/1Q9uo4r2u3WOZYg==
From: "Edward Wynn" <eddiew@oakleafconsultancy.com>
To: <users@tomcat.apache.org>

------_=_NextPart_001_01C5E398.8555122A
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,

=20

I am running Tomcat 5.0.28 and am having some problems with session
invalidation / timeout that I would like some help with.

=20

My application has a session-timeout of 5 minutes, and in my development
and test environments sessions are correctly invalidated by tomcat when
the timeout period is reached. At this point my class (method
valueUnbound) which implements HttpSessionBindingListener is called and
I am able to tidy up the session as I require.

=20

In my production environment I am coming across a problem where some
(but not all) sessions are not being invalidated once the timeout period
elapses. I have written some extensions to the manager application that
allow me to list all sessions for a Context and to subsequently force an
invalidation of sessions whose idle time is greater than a parameter I
pass to the tool. Using these tools I can see long lists of sessions
with idle times far in excess of 5 minutes - if I leave the system long
enough the idle times extend into 48 hours and beyond... If I then use
my tool to force session invalidation I can locate and invalidate these
sessions - at which point my valueUnbound method is run and session
clean up executes as expected - to me this proves that there is nothing
inherently wrong with the session itself (i.e once it is invalidated it
can be cleaned up as desired - there is nothing in the session that is
stopping this clean-up).

=20

I have spoken to the groups of users most affected by this problem and
have gone to great lengths to try to reproduce the problem in my test
environment using the same systems / connection methods and system usage
methods as they do but I have not managed to reproduce the problem.

=20

I have compared the configuration of the machines and they are identical
except that in production I have commented out the following default
connectors: SSL Coyote,  AJP1.3 and Proxied HTTP 1.1 - in other words
only the non-SSL Coyote HTTP 1.1 connector is available.

=20

Has anyone else come across this or a similar problem?=20

What did you do to fix it?=20

Has anyone any advise or pointers on what they think might be wrong
here?=20

Could someone offer a brief explanation of how Tomcat session expiry
works so that I would know which areas to focus my attention on?

=20

Many thanks in advance, Eddie


------_=_NextPart_001_01C5E398.8555122A--