commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <>
Subject Re: Commons logging and memory leaks
Date Wed, 18 May 2005 07:42:24 GMT
Hi David,

On Wed, 2005-05-18 at 08:56 +0200, David Perez wrote:
> I have created a web app, integrated with a web server called Jetty. 
> Both of them use commons-logging 1.5 alpha1. 
> There is just one set of jars shared between them. 
> The optional package is included, so weak references must be active.
> I have implemente webapp reload, by throwing the old class loader and 
> creating a new one.
> I have observed with the help of a memory profiler, that the  old class 
> loader isn't memory garbaged. 
> The cause is the log references.  The garbage roots are that maintain 
> live references are:
>     * static HIERARCHY in org.apache.log.Hierarchy
>     * static log in org.mortbay.util.URLResource and some other Jetty
>       classes that use Commons Logging.
> I have tested under Java in Windows XP.
> Can someone please give me some indications?
> Is it best to have separate commons-logging instances between my web app 
> and the web server?

Firstly, I presume you mean commons-logging-1.0.5-alpha1? Note that this
really is rather experimental; I presume jetty didn't come with this
version of commons-logging?

There are some cases which the weak-reference stuff cannot handle. And
even the weak-reference stuff works, commons logging cleans up but the
underlying logging library may not.

I suggest registering a ServletContextListener. Declare a <listener>
element in the web.xml file, with a nested <listener-class> element
containing the fully qualified classname of a logging-cleanup class. In
the contextDestroyed method of that class do this:
 * LogFactory.release(
 * somehow cleaning up the underlying logging library if needed.

If that doesn't help, let me know and we can look into it a bit



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message