> 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
