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
