Bug 51862 - JreMemoryLeakPreventionListener enhancement to load configurable classes
Summary: JreMemoryLeakPreventionListener enhancement to load configurable classes
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 7.0.21
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-21 21:56 UTC by Sylvain Laurent
Modified: 2011-10-12 21:48 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sylvain Laurent 2011-09-21 21:56:46 UTC
Enhancement proposed : add a "classesToInitialize" parameter to JreMemoryLeakPreventionListener to provoke the loading of arbitrary classes.
This will allow users to tune the memory leak protection features to avoid leaks triggered when loading JRE classes not yet identified as leaky, or even third-party classes.

I'll commit a patch in the next days...
Comment 1 Sylvain Laurent 2011-09-22 20:36:59 UTC
Committed to trunk and tc7, will be available in tomcat 7.0.22.

Proposed backport to tc6

http://svn.apache.org/viewvc?rev=1174359&view=rev
Comment 2 Konstantin Kolinko 2011-10-11 11:33:18 UTC
Added to 6.0 in r1181719 and will be in 6.0.34.
Comment 3 Christopher Schultz 2011-10-11 15:50:29 UTC
It seems like this feature could be used to reduce the amount of code in JMLPL by providing a default list of classes to load, since that's mainly what's going on in there.

Is that worth it, or is it better to handle the cases we already handle and leave this feature for use with webapp-specific (e.g. private) classes?
Comment 4 Konstantin Kolinko 2011-10-11 23:34:11 UTC
If you have predefined list of classes, what will this configuration property do: add to it, or replace it?

If it adds to it, how you remove items from predefined list (that is currently done by setting some properties to false) - by editing catalina.properties?

In general it makes sense, because it is easier to edit some default list (if we have to add some new classes to it in the default configuration) than introduce new setters and property name.
Comment 5 Sylvain Laurent 2011-10-12 05:03:18 UTC
It would indeed simplify JMLPL but would break the existing "API" if the setters and getters were removed. Or we can refactor to have the flag setters merely add some known class names to the set of classes to load.
Comment 6 Christopher Schultz 2011-10-12 21:48:44 UTC
Konstantin: good point about add/remove/replace... I hadn't thought too hard about that. Some of the classes loaded should only be loaded if the user wants them loaded (e.g. AWT-related stuff, optional libraries, etc.) so there probably shouldn't be a far-reaching default.

Sylvain: the API can be (somewhat) simply refactored to modify a list of classes to load.

I'll think about it and log another enhancement request with a more well-thought-out description.