0003031: memory leak for security context

Mantis - Resin
Viewing Issue Advanced Details

ID:	Category:	Severity:	Reproducibility:	Date Submitted:	Last Update:
3031		minor	always	10-30-08 08:10	11-03-08 12:13

Reporter:	ferg	Platform:
Assigned To:	ferg	OS:
Priority:	normal	OS Version:
Status:	closed	Product Version:
Product Build:		Resolution:	fixed
Projection:	none
ETA:	none	Fixed in Version:	3.1.8

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 (http://ampedandwired.com/2008/05/05/finding-permgen-memory-leaks-with-yourkit/ [^] 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 http://bugs.caucho.com/bug_view_advanced_page.php?bug_id=2883)? [^] 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)
Steps To Reproduce:
Additional Information:
Relationships
Attached Files:

Notes