Tomcat - sessions do not expire

[Wim Folkerts]

Hello,

Last week we've implemented a sessionListener implementing the HttpSessionListener interface. This week I found out a lot of sessions are not expired at all. In the Tomcat logging I print a line with date/time and sessionID when the session is created and the same when a session is destroyed. However based on the session ID I find out a lot of sessions are not destroyed at all. We know that most users do not use the logout functionality (who does). So in most cases the browser is just closed and the session should be expired after 30 mins of inactivity.
We're using Tomcat 6.0.18 and in the ../conf/web.xml we've confirgured the sessionTimeout as follows:

<session-config>
<session-timeout>30</session-timeout>
</session-config>

I've tried to reproduce this problem on my local environment, but all sessions does expires as expected. Note that a lot of users are using Citrix. Could that cause the problem we have as the user has activated a session as a system account instead of a user account?

Any advice would be appreciated.

-WFO

[Jaikiran Pai]

Wim Folkerts wrote: So in most cases the browser is just closed and the session should be expired after 30 mins of inactivity.
.....
I've tried to reproduce this problem on my local environment, but all sessions does expires as expected.

Are you sure that the browser session is closed? A wild guess (i don't know the details of your app) - maybe the browser is left open and your client application keeps sending a behind the scenes request to the server, which results in the session remaining active.

[Wim Folkerts]

Yes, I'm very sure the browser is closed. Just for you info - I managed to reproduce this also on the production environment. I also found out it has nothing to do with Citrix as it also happens in our internal network. So the situation is that a lot of sessions on our production environment are not closed while this is not the case on my local development environment . We've been migrated from Websphere 4.0 to Tomcat 6 for about 4 months. We had the problems before the Inital heap was increased to 256 MB and the Max Stack to 512 MB where Tomcat just went down due to the high number of process but now we got issue where the max number of DB connections was exceeded; ORA-00020: maximum number of processes (500) exceeded

Btw I found an example servlet to close 'stale' sessions. But it would be better to find the root cause...

import java.io.*;
import java.util.*;
import javax.servlet.*;
import javax.servlet.http.*;

public class ManualInvalidate extends HttpServlet {

public void doGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException {
res.setContentType("text/html");
PrintWriter out = res.getWriter();

// Get the current session object, create one if necessary
HttpSession session = req.getSession(true);

// Invalidate the session if it's more than a day old or has been
// inactive for more than an hour.
if (!session.isNew()) { // skip new sessions
Date dayAgo = new Date(System.currentTimeMillis() - 24*60*60*1000);
Date hourAgo = new Date(System.currentTimeMillis() - 60*60*1000);
Date created = new Date(session.getCreationTime());
Date accessed = new Date(session.getLastAccessedTime());

if (created.before(dayAgo) || accessed.before(hourAgo)) {
session.invalidate();
session = req.getSession(true); // get a new session
}
}

// Continue processing...
}
}

Any help would be most appreciated.

[Tim Holloway]

The only thing that should keep sessions from expiring is if a request if made using that session ID before the expiration interval elapses.

Unfortunately, I don't think Tomcat has anything corresponding to the Apache access log so you can see the requests and hasn't since about Tomcat2. So it might be necessary to use a network trace tool to see if you can spot anything.

[Kris Schneider]

Tim Holloway wrote:Unfortunately, I don't think Tomcat has anything corresponding to the Apache access log...

Take a look in conf/server.xml and uncomment the valve that controls access logging. It will probably look something like this:

<!-- Access log processes all example.
     Documentation at: /docs/config/valve.html -->
<!--
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"
       prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="false"/>
-->

[Wim Folkerts]

Hello Kris,

Thanks for your reply. I've done this. I'm running Tomcat in Eclipse and when I restart Eclipse again with this line uncomment, I get the below error:
Could not initialize class org.eclipse.wst.server.ui.internal.provisional.UIDecoratorManager

Talking about the server.xml, Our connector is configured as shown below

<Connector port="80" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxThreads="200" />    
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/>

Maybe useful to uncomment the below line?

    
<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

Regards Wim

[Kris Schneider]

Wim Folkerts wrote:I'm running Tomcat in Eclipse and when I restart Eclipse again with this line uncomment, I get the below error:
Could not initialize class org.eclipse.wst.server.ui.internal.provisional.UIDecoratorManager

Can't help with that one, but I'd try running Tomcat outside of Eclipse.

Wim Folkerts wrote:Maybe useful to uncomment the below line?

    
<Connector executor="tomcatThreadPool"
               port="8080" protocol="HTTP/1.1" 
               connectionTimeout="20000" 
               redirectPort="8443" />

You already have a connector for HTTP on port 80...

[Wim Folkerts]

That's me back again. This seems to be a known bug in Eclipse but I managed to solve this by doing the below:

The following error message in Eclipse:

An error has occurred. See error log for more details.
Could not initialize class org.eclipse.wst.server.ui.internal.provisional.UIDecoratorManager

is a known bug.

There is no official solution, but people are reporting luck if they start Eclipse in the Java EE perspective and with the Servers tab visible.

Anyway the server is running now. As I did not specify the CATALINA_HOME I put this in my environment variables: C:\Program Files\Apache Software Foundation\Tomcat 6.0

However I don't get any logging info in the tomcat ..\logs directory. Did I forget something? This is what the Tomcat reference guide is saying:

Absolute or relative pathname of a directory in which log files created by this valve will be placed. If a relative path is specified, it is interpreted as relative to $CATALINA_HOME. If no directory attribute is specified, the default value is "logs" (relative to $CATALINA_HOME).

[Kris Schneider]

Take your IDE out of the equation and run Tomcat on its own. If you use Tomcat's startup script, CATALINA_HOME should get set automatically.

[Wim Folkerts]

Ok, I've just uncommented the line in the server.xml and now I get logging info. I get debug info like:
134.146.136.24 - - [12/Mar/2010:08:46:14 +0100] "GET /scripts/eds3_1.js HTTP/1.1" 304 -

Next I've cleaned the tomcat work folder just to be sure.

But how can I use this debug info for my session problem?

[Tim Holloway]

Oh yeah. I've got major gripes with how Eclipse WTP runs Tomcat. As I've mentioned before, it knows just enough about Tomcat's insides to be dangerous, and not enough to be helpful - particularly about arcane server.xml settings. I much preferred the old sysdeo plugin, but alas, it seems to have dropped out of the running.

If you follow the access logfile, you'll see that every time an HTTP request is made to the server, an entry is written to the log. That entry should include the URL being requested as well as the originating IP address.

If you see requests coming in at times and at intervals that they shouldn't be, they probably include the requests that keep your sessions from timing out.

I think there's a log formatting option that will also display the offending user's login ID, although that may be useless if you're running a DIY security system.

[Wim Folkerts]

Thanks Tim for the advice.
I'm now using the sysdeo plugin which work fine too and yes the logging now also works local. I cost me some time because I did not set the JAVA_HOME environment variabele I'll check if it is possible to have the sessionID added in the access_log and let you know. Although I don't think these requests are causing the problem that sessions do not time out. This because I also found out that sessions where expired when I'm trying to use the application again. Maybe a problem with the garbage collection or something?

[Wim Folkerts]

Back again.. Currently the server.xml has the (default) line:

    
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"  
            prefix="localhost_access_log." suffix=".txt" pattern="common" resolveHosts="true"/>

You can simply change the value of the pattern property (see: http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html):

    
<Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"  
            prefix="localhost_access_log." suffix=".txt" pattern="%a %l %u %t %r %s %b %S" resolveHosts="true"/>

The "%S" is displaying the sessionID. Let's see if we can find some "lost" sessions on production.

[Wim Folkerts]

Hello,

This morning I put the sessionID in the loggin information of Apache. I found out the session ID is never just in any request meaning it will stay inactive while the session will not validate at all.
Maybe there is a problem with the garbage collection? I am not able to reproduce this problem on my development or acceptance environment.

Can anyone help me with this?

Thanks,

Wim