Mailing-List: contact commons-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Users List" <commons-user@jakarta.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of mail-lists@revolsys.com
 designates 64.34.51.4 as permitted sender)
Subject: Re: [logging] lon4j only implementation to solve out of memory
	errors
From: Paul Austin <mail-lists@revolsys.com>
To: skitching@apache.org
Cc: Jakarta Commons Users List <commons-user@jakarta.apache.org>
In-Reply-To: <1122353923.3771.27.camel@localhost.localdomain>
References: <1122319554.7732.40.camel@chief.int.revolsys.com>
	 <1122353923.3771.27.camel@localhost.localdomain>
Content-Type: multipart/alternative; boundary="=-BduYhIN9ZZqsDA6oG9r0"
Date: Tue, 26 Jul 2005 08:09:28 -0700
Message-Id: <1122390568.4207.22.camel@chief.int.revolsys.com>
Mime-Version: 1.0

--=-BduYhIN9ZZqsDA6oG9r0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

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
> 

--=-BduYhIN9ZZqsDA6oG9r0--