[Bug 53936] Minimize classloader leaks from stacktrace elements in long-lived Exceptions

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=53936

Konstantin Kolinko <kn...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #4 from Konstantin Kolinko <kn...@gmail.com> ---
> MemoryLeakProtection in the Tomcat wiki says: "Sun bug 6916498 - An
> exception can keep a classloader in memory if the stack trace that was
> recorded when it was created contains a reference to one of its classes."

(In reply to comment #3)
> The intended use of this code is for the WebappClassLoader to clean up
> Exceptions that are created and held by third-party libraries included in a
> webapp when the webapp is unloaded. 
> 

For reference:

http://wiki.apache.org/tomcat/MemoryLeakProtection
https://issues.apache.org/bugzilla/show_bug.cgi?id=50460

1. First, I think that there will not be a leak in your scenario.

Tomcat already has code to clear static fields in classes that belong to a web
application.  Note though that it is possible only because those classes are
loaded through Tomcat's own WebappClassLoader class. It holds references to all
classes that it loaded.


The scenario where I observed this memory leak issue was different. See bug
50460 for details. The Exception instance was being hold by a shared library,
not by webapp one:

1) A webapp does its first call to a shared library or to Tomcat server code.
2) A class from the shared library is loaded and creates an Exception instance.
3) That exception holds reference to the calling webapp class.


2. If a library caches an Exception instance and has such a leak, it is a bug
in that library. It is up to the authors of that library to fix their bug, e.g.
by implementing fillInStackTrace() as a NOOP, like we did in
ImmutableNameNotFoundException.

3. Each "class scanning" solution takes noticeable time, because usually there
are a lot of classes. It is not worth here.

If there is no way to fix a library, one could implement a "targeted" solution:
write a listener to perform cleanup in their specific case.

4. If the leak occurs in a shared library, I see no sane way to enumerate
loaded classes (and thus to apply your solution). A good news is that there is
an alternative solution: you can preload those classes.

A list of classes to preload is already configurable on
JreMemoryLeakPreventionListener.


Thus I am closing this issue as WONTFIX.

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org