geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Workaround for URLJarFile memory leak
Date Fri, 11 Nov 2005 19:08:49 GMT
Maybe we should put this in the CommandLine class in the static block  
at the top, and in Daemon line 153.  Basically before we initialize  
the logging system.  These are the places where we put global  
initialization code.  Actually now that I think about it, it would be  
nice to have a single place we put this type of static global  
initialization code.


On Nov 11, 2005, at 8:50 AM, Jeff Genender wrote:

> Comments????
> How about nice work! ;-)
> I don't see any issues.  If the others don't see problems, I will  
> be happy to apply your patch...just assign it to me.
> Jeff
> Kevan Miller wrote:
>> As I mentioned previously, there is a memory leak of URLJarFile  
>> instances in
>> Geronimo. The problem is caused by
>> --
>> will hold onto strong  
>> references to
>> all URLJarFile instances. So URLJarFiles can never be GCed. This  
>> means that
>> for every deploy/undeploy of an application, you'll leak URLJarFiles.
>> The problem can be avoided by calling  
>> URLConnection.setDefaultUseCaches(false);
>> This will turn off the caching in JarFileFactory. I added a call to
>> setDefaultUseCaches() to DeploymentUtil.readAll() and verified  
>> that Geronimo
>> no longer leaks URLJarFile instances.
>> Note that setDefaultUseCaches(false) is a "global" setting. So it  
>> affects
>> the entire runtime. URLConnection.setUseCaches(false) does not fix  
>> the
>> problem. Since, there is the potential for a performance impact, I  
>> thought
>> I'd advertise the issue. I don't see any usages within Geronimo  
>> code where
>> this would cause major problems. However, there may be issues  
>> which I'm not
>> realizing...
>> Comments? Barring concerns, I'll raise a Jira and post a patch.
>> --kevan

View raw message