...

1. You'll need a profiler (I use YourKit), Tomcat and a copy of the app that leaks.
2. Configure Tomcat for use with the profiler. This usually means setting / adding to PATH and CATALINA_OPTS in setenv.(bat|sh)
3. Start Tomcat with the app deployed.
4. Reload the app once.
5. Start up the profiler and connected it to Tomcat.
6. Get a heap dump.
7. Look for instances of WebappClassLoader. If there are more instances than you have apps deployed, you have a leak.
8. If there is a leak, there should be one extra instance of WebappClassLoader.
9. Examine each of the WebappClassLoader objects in turn to find the one where started==false.
10. Trace the GC roots of this object to find out what is holding on to a reference to that object that shouldn't be. That will be the source of the leak.
    

...

HTTP sessions

(In response to [1], [2])

Please remember that a JSP page, even one that simply prints out “OK”, will create a session. This is by design and if you do not want it to create a session you need to explicitly indicate that in your JSP. For example:

  <%@ page session="false" %>

This is important in scenarios where you are doing load testing and using custom HTTP clients, because these clients may not be handling sessions correctly and thus end up creating a new session every time they access the page.

One known category of misbehaving clients are web bots. To deal with them you can configure a CrawlerSessionManagerValve.

It is also possible to limit the number of active sessions by setting maxActiveSessions attribute on a Manager element, e.g.

<Context>
<Manager maxActiveSessions="500" />
</Context>

...

CategoryFAQ