Releasing memory on undeploy

2005-03-18 Thread Simon Kitching
Hi,

I'm one of the committers on commons-logging and am currently looking
into memory-leak issues with j2ee/servlet-engine stuff when undeploying
apps that use commons-logging.

I see the following page in the tomcat FAQ states that classloaders
cannot be garbage-collected in tomcat:
  http://jakarta.apache.org/tomcat/faq/deployment.html

Can someone confirm this is in fact true, and if so explain why?

Thanks,

Simon


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing memory on undeploy

2005-03-18 Thread Chris Hyzer
 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

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: Releasing memory on undeploy

2005-03-18 Thread Simon Kitching
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]