Overall I think this is a rock-and-a-hard-place issue.
ThreadLocals work wonderfully behind opaque library walls in most cases.
The exception is when there are threads used with your library whose
lifecycle is beyond that of the classloader which loads your library --
as in Tomcat web apps, for instance. Working around this can force
library authors to have init() and destroy() methods for their library
to clean up ThreadLocals, which isn't at all nice for library authors
(as no try { /* stuff setting thread locals */ } finally { /* remove
thread locals */ } isn't really always a workable pattern for all
libraries).
This is a pervasive enough pain that I'm beginning to think that there
should be a web app reload mode which marks all existing threads as
"dirty", i.e. to be replaced at the end of the current request in
progress (or immediately if no request is in progress). Sure, this cuts
down on the performance of web app reloading, but it solves the problem
in its entirety without asking all library authors to rewrite their
libraries!
--
Jess Holle
On 8/30/2010 4:08 PM, Caldarale, Charles R wrote:
From: Bill Davidson [mailto:bill...@gmail.com]
Subject: iCal4j and ThreadLocal
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's just creating some small static variables on per thread basis.
"All I changed was..." No, it's doing a lot more than that.
I'm not really clear on how ThreadLocal works.
http://download.oracle.com/javase/6/docs/api/java/lang/ThreadLocal.html
And, as usual, GIYF.
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.
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:
http://tomcat.apache.org/tomcat-6.0-doc/config/listeners.html
but that pretty much means that, for safety's sake, you should restart Tomcat
on every webapp deployment.
- Chuck
THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
MATERIAL and is thus for use only by the intended recipient. If you received
this in error, please contact the sender and delete the e-mail and its
attachments from all computers.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
