On 8/31/2010 4:03 AM, Leon Rosenberg wrote:
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.
While I think it would be *nice* of a container to replace threads on a
web app redeploy/restart, I wouldn't go so far as to say that not doing
so is a bug. Do OSGi containers raise similar issues with module
redeployment? I'd guess so -- and guess that replacing threads might be
harder in such cases.
That said, replacing threads in a web app container seems fairly
straightforward and seems like a more friendly approach than telling
library authors to rework their code or trying to remove thread locals
in a non-thread-safe fashion.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
