So I've spent another day hunting that lo(ooo)ng standing PermGen memory
leak in our application and/or Resin.
I made a new discovery which "shouldn't" be an issue, but could
potentially fix problems.
From my investigation it seems that whenever the application is
reloaded, a reference to the old
com.caucho.loader.EnvironmentClassLoader is kept in
com.caucho.hessian.io.SerializerFactory._defaultFactory. I agree that in
theory this shouldn't happen, since the ClassLoader is a weak reference
key, /however/ if I add some code to the application shutdown,
explicitly removing the EnvironmentClassLoader from _defaultFactory
using reflection, the garbage collector is able to unload these classes.
I should mention though, that there is still a minimum of two
EnvironmentClassLoaders for the given application after reloading at
least once. The former one seem to stick around somehow. We have
discussed this before, Scott; how references are kept inside
com.caucho.server.dispatch.Invocation, at least in a low traffic (dev /
debugging) environment. Not sure if this a real problem, but ideally the
class loader of the previous version should be available for garbage
collection before the classes of the new version are loaded ('cause
there is no turning back anyway, is there...?). Otherwise you always
have to set MaxPermSize to at least twice as much as the application
actually needs.
In some profiling session I've also seen references from logging and
"index-cache-writer" threads, which might be worth looking into.
Scott, could you tell me if anything can be done to the issues mentioned
above?
--
</Mattias>
_______________________________________________
resin-interest mailing list
[email protected]
http://maillist.caucho.com/mailman/listinfo/resin-interest
