On Tue, Aug 31, 2010 at 10:51 AM, Ognjen Blagojevic <ognjen.d.blagoje...@gmail.com> wrote: >>>> 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. > > Other solution is to create a new thread by yourself and delegate the iCal4j > work to it. Once the thread is finished, ThreadLocal variables are also > released. We managed to work around similar leak in older JasperReports > library like that. > > Be aware, however, that creation of threads takes some resources, and that > you should take necessary steps to clean up those threads in all cases (when > exception is thrown in the thread, or when the server shuts down while your > thread is still active).
The more I think about the issue, the more I feel that this is a bug in the container which defines two different lifecycles one for webapps and one for threads which use the webapps, and, in case of ThreadLocal, contain the webapp code. As a library developer I can not be aware that I'm running in a container and how this particular container defines its and my lifecycles. Providing a ServletContextListener for each container along with my small logging library (example) seems a little overkill. The cleanest solution would be to either have an executor service per webapp (which will be tricky to become effective) or to replace all threads in the thread pool on redeploy. Correct me if I'm wrong, but hot-redeploy isn't meant as production system feature anyway (at least it wasn't time ago), and the performance impact for thread pool renewal on a staging system is negligible. 2 cents. regards Leon > > Regards, > Ognjen > > --------------------------------------------------------------------- > 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
