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 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 



resin-interest mailing list

Reply via email to