Just tried a new idea: I subclassed EnvironmentClassLoader within the Resin sources and compiled into resin.jar. There is still a leak (in contrast to when I subclassed EnvironmentClassLoader within my own application).
Conclusion: The classloader that loads the (Environment)ClassLoader class is somehow of importance. /Mattias Mattias Jiderhamn wrote (2009-03-30 08:40): > Daniel, your findings confirms EnvironmentClassLoader as the prime > suspect (my own tests are a bit more detailed in an earlier post, > http://maillist.caucho.com/pipermail/resin-interest/2008-November/003158.html) > > Regarding your GC root paths for this class: > 1. I haven't noticed any uses of java.util.prefs - could this be part > of any of your added JARs (like groovy)? > 2. This is the error I have found within Resin that is still to be > fixed. As mentioned earlier, there is a quick and dirty patch for > Resin 3.1 available at http://jiderhamn.se/resin-leak.patch to avoid > this leak. However even with the patch applied I'm still having leaks. > 3. This obviously seems like a groovy problem, probably a static > initialization triggered at class load. > > So would you mind giving this another try with groovy removed and with > a patched version of Resin? (I can provide a patched resin.jar if that > helps) > > Cheers, > Mattias Jiderhamn > > Daniel Lopez wrote (2009-03-29 14:52): >> Hi, >> >> Using that .war as a sample application, I did some more tests and >> found some things that might be interesting: >> >> I added groovy-1.5.7.jar, hibernate-3.2.6.ga.jar and >> scala-compiler-2.7.2.jar to WEB-INF/lib. Nothing is done with them, >> they simply live there. Important data: total size for WEB-INF/lib: >> 10.3 MB. >> >> I then deployed the application, start it and here's some data I >> gathered after accessing the application a couple of times and hitting >> "Force Garbage Collector" until the memory is stable: >> >> Heap Memory used: 31MB >> Instances of com.caucho.loader.EnvironmentClassLoader: 1 >> >> I then re-save web.xml so the context is reloaded, access and force GC >> until memory is stable again: >> >> Heap Memory used: 41MB >> Instances of com.caucho.loader.EnvironmentClassLoader: 2 >> >> Once again: >> >> Heap Memory used: 51MB >> Instances of com.caucho.loader.EnvironmentClassLoader: 3 >> >> Focusing on the last memory snapshot the 3 EnvironmentClassLoader come >> from (shortest GC roots): >> 1.- contextClassLoader of >> java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, >> Thread] >> 2.- _classLoader of com.caucho.server.dispatch.Invocation -> >> _invocation of com.caucho.server.http.HttpRequest [Stack Local] -> >> 3.- <loader> of org.codehaus.groovy.tools.shell.util.Preferences$1 -> >> <class> of org.codehaus.groovy.tools.shell.util.Preferences$1 -> >> [1] of java.util.prefs.PreferenceChangeListener[3] -> >> prefListeners of java.util.prefs.WindowsPreferences -> >> STORE of org.codehaus.groovy.tools.shell.util.Preferences -> >> [771] of java.lang.Object[2560] -> >> elementData of java.util.Vector -> >> classes of com.caucho.loader.EnvironmentClassLoader -> >> contextClassLoader of >> java.util.prefs.AbstractPreferences$EventDispatchThread [Stack Local, >> Thread] >> >> They are ordered using order of appearance (in the first memory SS, >> one like 1 is present, after the first restart one like the 2 is >> present). >> >> And looking at one of the suspected classes to be replicated, >> org.codehaus.groovy.tools.shell.util.Preferences, you can see that >> indeed there are 3 instances of that class, each one loaded by a >> different EnvironmentClassLoader. >> >> So, I would say there is indeed a leak and the jackpot would be to >> find out why the EnvironmentClassLoader instances are not being >> cleaned. Without knowing how Resin is internally supposed to work and >> which loaders are supposed not to be there, it's difficult to know. As >> the classes inside the lib directory are not even used at all, one >> would suspect is a Resin internal issue, but seeing Preferences >> classes and ThreadLocal in the mix makes the whole thing quite >> suspicious :). >> >> Any idea or test to find out more? >> D. >> >> >>> Seems to me nothing has changed in this regard in the 4.0 snapshot. I >>> did my leak test as previously described, see below, and no classes were >>> unloaded. >>> >>> - Dowload http://jiderhamn.se/leak.war >>> - Add some JARs to the WEB-INF/lib directory; preferrably a couple of >>> large ones like spring.jar and hibernate.jar (don't use Resin JARs though). >>> - Drop the WAR in a clean installation of Resin >>> - Hit http://...:nn/leak (once is enough) >>> - Force a redeploy by either deleting the webapps/leak dir or touch:ing >>> leak.war >>> - Hit http://...:nn/leak again >>> - Repeat the last two steps for as long as you'd like >>> >>> /Mattias >>> >> >> >
_______________________________________________ resin-interest mailing list [email protected] http://maillist.caucho.com/mailman/listinfo/resin-interest
