tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Braun <brianbr...@gmail.com>
Subject Re: Leak in Tomcat 7.0.11: a java.util.Timer seems to leave a timerThread in the JVM, and Tomcat says "...has failed to stop it. This is very likely to create a memory leak"
Date Sat, 30 Jul 2011 15:50:29 GMT
Hi Konstantine,

I read all the thread, but I didn't find any conclusive response. Here are
my doubts/comments, after everything I have read:

- My timer creates a thread, with a name I assign to it. After my app stops,
I see the thread in the JVM using the Yourkit profiler. It is clear that the
thread is still there, but doing absolutely nothing (it does show any color
trace in the profiler). As far as I have noticed, it dissappears after a
while. Somehow, the JVM realizes the timer was already canceled, and that
for that reason the thread can/must be killed. Am I right?

- When Tomcat checks for leaks, it finds that the timer thread is there, and
that it is related to the same classloader that is related to the app, and
then warns that it could be a leak. Tomcat doesn't check if the timer has
already been canceled and therefore going to dissapear in a while, it just
checks that its thread is linked to the app by the same loader and that the
thread still exists. Or am I wrong?

What should I really do?

1- Should I try to kill the thread somehow? I don't even know how to get a
reference to that thread.
2- Should I try to understand how Tomcat kills the thread in its code, and
do it myself copying the code?
3- Should I just wait for a couple of seconds, inserting a delay in the
contextDestroyed() method, so as to give time to the task object to finish
doing whatever it does when cancelling? I don't think that would be
reliable.
4- Should I set the parameter clearReferencesStopTimerThreads="true" in the
context, to tell Tomcat to kill the threads linked to the same loader? That
would make Tomcat to leave a warning in the log also (I would prefer a clean
log instead), but at least the manager would not tell me that a leak was
found, when I press the "Find leaks" button. If I use that parameter, what
will happen if there is another timer in the future that should not be
killed, and it will kill it without me knowing about it?
5- Or should I just do nothing, and accept that even if the manager thinks
there is a leak, it is just the timer thread that will dissappear eventually
and that no leaking is really happening?




On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko
<knst.kolinko@gmail.com>wrote:

> 2011/7/30 Brian Braun <brianbraun@gmail.com>:
> > How do I solve it? Do I need to kill the thread somehow, or should it die
> as
> > soon as I cancel the timer with the timer.cancel() method?
>
> It was discussed recently. See thread "Terminating Timer Thread
> Gracefully" starting with July 12th.
>
> Best regards,
> Konstantin Kolinko
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message