Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0003031 [Resin] minor always 10-30-08 08:10 11-03-08 12:13
Reporter ferg View Status public  
Assigned To ferg
Priority normal Resolution fixed  
Status closed   Product Version
Summary 0003031: memory leak for security context
Description (rep by Mattias Jiderhamn)

Although embarrassed to admit it, we have had long standing problems
with PermGen memory leaks. We have gotten used to restarting the server
every time we redeploy, to avoid OutOfMemoryError. Since we would like
to make use of - or at least evaluate - some of the new Resin features
like WAR versioning, I thought I?d give fixing this another shot.

I have already been through (and fixed a few of) the usual suspects;
JDBC drivers, log factories, ThreadLocals, explicit ClassLoader
references etc. There has also been at least one bug within Resin
causing leaks (bug 951 in Mantis).

A while back I tried tracking this down using jhat, but since I have
limited experience with this, time did not allow me to get to the bottom
of it. Today I found some more time, and also a tip on how to use
YourKit to track this down
( [^]
for those interested). This lead me to something interesting, which I
don?t quite understand.

If I interpret the YourKit memory snapshot correctly, here is what is
happening (from a Resin 3.1.6 perspective):

In com.caucho.server.dispatch.ServletInvocation there is a static
ThreadLocal holding references to the current (original) request (while
dispatching?). This means that as long as the executing (and
dispatching) thread remains in Resins thread pool, but is not used for
another dispatch, a handle to the original
com.caucho.server.http.HttpRequest is held. In the request, there is a
handle to a com.caucho.server.dispatch.Invocation, which in turn has a
handle to - the application classloader! (And there is your PermGen leak)

Isn?t the fact that the ThreadLocal is never cleared an obvious memory
leak? Or why haven?t this been fixed even though Scott seems to have
noticed this (see [^]
If the leak actually is in Resin, why isn?t anybody else seeing this???
Are we doing something unusual? (The only thing I could think of was
ServletRequest implementations inside the application being dispatched,
however I can't find any such implementations in use)

Additional Information
Attached Files

- Relationships

- Notes
11-03-08 12:13

SecurityContext management put in startInvocation/finishInvocation and put in finally block.

- Issue History
Date Modified Username Field Change
10-30-08 08:10 ferg New Issue
10-30-08 08:14 mate Issue Monitored: mate
10-31-08 01:58 cwhalley Issue Monitored: cwhalley
11-03-08 12:12 ferg Assigned To  => ferg
11-03-08 12:12 ferg Status new => closed
11-03-08 12:12 ferg Resolution open => fixed
11-03-08 12:12 ferg Fixed in Version  => 3.1.8
11-03-08 12:13 ferg Note Added: 0003529

Mantis 1.0.0rc3[^]
Copyright © 2000 - 2005 Mantis Group
32 total queries executed.
27 unique queries executed.
Powered by Mantis Bugtracker