On 30/08/2010 22:08, Caldarale, Charles R wrote:
>> From: Bill Davidson [mailto:bill...@gmail.com] 
>> The iCal4j author assures me that this isn't really a memory leak.
> 
> I suppose it depends on your definition of memory leak, but I'd certainly 
> consider it one.  It adds to the heap, and doesn't go away automatically when 
> the application is undeployed (and likely prevents complete undeployment).  
> Furthermore, when the application is redeployed, you'll get an additional set 
> per thread, since the net.fortuna.ical4j.* classes will be loaded from a new 
> classloader.

It is going to pin every class loaded by your web application in memory
when the app is reloaded. By pretty much any definition of the term,
that is a memory leak in PermGen.

>> Is there no way for me to kill these?
> 
> Not easily.  Most uses of ThreadLocal seem to be blissfully (sometimes 
> arrogantly) unaware of thread-pooling mechanisms and app servers.  Ideally, 
> these ThreadLocal instances would instead be created in a pool for the webapp 
> to use, rather than being tied to individual threads.

6.0.26 removes those by default. 6.0.29, removing them is optional - see
 the clearReferencesThreadLocals attribute on the context.

The only way to get rid of the messages is to fix the memory leak.

>> Alternatively, if it really is harmless, is there a way to
>> turn off these messages?
> 
> It's not harmless.  I think you can inhibit the checks by disabling the 
> JreMemoryLeakPreventionListener:

'Fraid not.

The right solution here is for the iCal4j library to fix the leak or
provide a mechanism to enable clients to trigger clean-up on shutdown
(which can then be called from a Servlet context listener). Generally,
library authors have moved quickly to fix the leaks when reported.
log4j, Spring Batch, commons-lang are the ones I can recall and I am
sure there have been others.

Mark



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Reply via email to