Daniel, your findings confirms EnvironmentClassLoader as the prime
suspect (my own tests are a bit more detailed in an earlier post,

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)

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

Reply via email to