Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 14486 invoked from network); 18 May 2005 07:45:08 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 18 May 2005 07:45:08 -0000 Received: (qmail 33047 invoked by uid 500); 18 May 2005 07:42:30 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 32615 invoked by uid 500); 18 May 2005 07:42:26 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 32357 invoked by uid 99); 18 May 2005 07:42:19 -0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from mta205-rme.xtra.co.nz (HELO mta205-rme.xtra.co.nz) (210.86.15.187) by apache.org (qpsmtpd/0.28) with ESMTP; Wed, 18 May 2005 00:42:15 -0700 Received: from pop1-rme.xtra.co.nz ([210.86.15.240]) by mta205-rme.xtra.co.nz with ESMTP id <20050518074131.XDYI11967.mta205-rme.xtra.co.nz@pop1-rme.xtra.co.nz> for ; Wed, 18 May 2005 19:41:31 +1200 Received: from [10.1.1.9] ([210.86.108.123]) by pop1-rme.xtra.co.nz with ESMTP id <20050518074130.BKSJ7985.pop1-rme.xtra.co.nz@[10.1.1.9]> for ; Wed, 18 May 2005 19:41:30 +1200 Subject: Re: Commons logging and memory leaks From: Simon Kitching Reply-To: skitching@apache.org To: Jakarta Commons Developers List In-Reply-To: <428AE721.8020400@yahoo.es> References: <428AE721.8020400@yahoo.es> Content-Type: text/plain Date: Wed, 18 May 2005 19:42:24 +1200 Message-Id: <1116402144.3836.34.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N 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 1.5.0.03 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 element in the web.xml file, with a nested element containing the fully qualified classname of a logging-cleanup class. In the contextDestroyed method of that class do this: * LogFactory.release( Thread.currentThread().getContextClassLoader()) * 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 further. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org