On Fri, 2005-03-18 at 18:48 -0800, Chris Hyzer wrote: > > currently looking > > into memory-leak issues with j2ee/servlet-engine > > We have about a dozen apps on 2 tomcats that have > 800MB each in linux (5.0.25), and they are not huge > apps, but after a few manager reloads the tomcat is > out of memory. Is this related? You said undeploy, > but maybe reloading is also a problem. Also, if we > let the server run for a while, we cannot add new apps > either. I suspect we need to profile and look for > memory leaks, but I thought it would mention it. Chris
It might be the same problem. By "undeploy" I mean "throw away the classloader associated with the deployed component", which reload will also do. The problem is that both commons-logging and commons-beanutils use the Singleton pattern. And the Singleton pattern is *extremely* hard (possibly impossible) to implement correctly in a j2ee-style environment when a class might be loaded via a "shared" classloader. Tomcat includes a workaround for commons-logging which appears *to me* to be a complete fix for commons-logging leaks (though maybe not a very elegant one): it calls org.apache.commons.logging.LogFactory.release(this) from class WebappClassLoader. However there have been reports of leaks when using commons-logging despite this; I need to try to set up some testcases to determine what's going on, but testcases involving garbage-collection and complex classloading setups will be tricky to create. If you do find anything from profiling your app, please post the info to this group (and/or me). Note that I'm going to be away for the next three weeks, but will try to pick this topic up when I return. Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
