commons-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Austin <mail-li...@revolsys.com>
Subject Re: [logging] lon4j only implementation to solve out of memory errors
Date Fri, 05 Aug 2005 18:36:43 GMT
Hi Simon,

I think adding the following ContextListener solved the problem.

http://static.springframework.org/spring/docs/1.1.5/api/org/springframework/web/util/IntrospectorCleanupListener.html

Paul

On Tue, 2005-07-26 at 08:09 -0700, Paul Austin wrote:

> Hi Simon,
> 
> I am running my application on Tomcat 5.5 under Sun JDK 1.4.2_07-b05 on
> Windows XP. For the production environment it will be Oracle Application
> Server 9.0.4.1 under JDK 1.4.2 on Solaris 2.8 (I haven't had access to
> test on that server yet).
> 
> The original discussion where I started to find out about the problem
> was on the hibernate forums.
> 
> http://forum.hibernate.org/viewtopic.php?t=935948&highlight=permgen
> 
> One of the things I tried was adding a context listener which had the
> LogFactory.release method called. There are also 3 filters which use
> springframework/hibernate which use libraries that may use
> commons-logging. I'm guessing that perhaps the destroy method on the
> filters is called after I call LogFactory.release thus some new log
> instances are created thus undoing the work in the release method.
> 
> I'll try to get a stripped down copy of the application that still has
> the issue put together to help solve this problem. Won't be this week as
> I have to deliver the application.
> 
> Cheers,
> Paul
> 
> On Tue, 2005-07-26 at 16:58 +1200, Simon Kitching wrote:
> 
> > 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message