commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kitching <skitch...@apache.org>
Subject Re: [logging] lon4j only implementation to solve out of memory errors
Date Tue, 26 Jul 2005 04:58:43 GMT
Hi Paul,

On Mon, 2005-07-25 at 12:25 -0700, Paul Austin wrote:
> I am using several of the other commons components and hibernate that
> use the commons-logging API to abstract from the underlying log4j or
> Java Logging APIs.
> 
> Unfortunately due to a bug in JDK 1.4 which does not release references
> to class definitions correctly when commons-logging is containing in a
> J2EE web application WAR file and the application  is redeployed. The
> only reliable solution is to deploy log4j and the commons-logging and
> commons-logging-optional (1.0.5-alpha) jar files as shared libraries for
> the entire J2EE server. That approach has worked well in my development
> environment.

I'm not sure what "bug in JDK 1.4" you're referring to. Do you have any
further info on this?

If commons-logging is deployed via a shared classloader and the servlet
engine is not commons-logging-aware then components such as webapps need
to ensure that LogFactory.release is called when they are undeployed in
order to avoid exactly the situation you describe. Note that Tomcat is
"commons-logging-aware" and does this automatically. This isn't a "bug",
it's a known cleanup step. The commons-logging-optional.jar does
*sometimes* remove the need for the call to LogFactory.release but not
always which is why I prefer to use LogFactory.release instead of or as
well as the optional jar.

I don't know of any situations where such a memory leak is *caused* by
having commons-logging in the component's WEB-INF/lib. More information
would be welcome.

What container (eg tomcat, jboss) are you using?

> 
> The application is however going to be deployed in a shared server that
> I have little control over and it is unlikely that I will be able to
> deploy these libraries as shared components as all the other
> applications have local log4j config files so it would require a lot of
> testing and tweaking of other applications to get everything to work
> correctly.

Yep, that's the problem of putting libs in a "shared" classloader. It's
an approach I don't like at all for exactly that reason.

> 
> One potential solution I can think for this is to create a clone of
> commons-logging that just provides the same interfaces but is statically
> bound to log4j so that it would not have to do all the lookups and
> caching of class references that goes on right now. This would be a
> similar thing to slf4j.org (UGLI) but with the existing commons logging
> interface so it can be dropped in as a replacement for commons-logging
> for other API's that already use it.

Yep, adopting some of the ideas from UGLI is something that has been
looked at. There are some definite benefits, but also some disadvantages
to this approach. Some prototyping of this has been done but nothing
that is likely to be released this year.


> Has anyone looked at this or know of any other solutions to the out of
> memory issues.

If you can provide more information I would be willing to help you look
into this. I don't see any reason why the current commons-logging
wouldn't work for you provided things are set up correctly.

Regards,

Simon


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-user-help@jakarta.apache.org


Mime
View raw message