tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <knst.koli...@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 16:27:23 GMT
2011/7/30 Brian Braun <brianbraun@gmail.com>:
> 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:

For reference:
http://markmail.org/thread/oph2acjbdptcvduf

>
> - 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?

In short, Timer.cancel() only prevents future execution of the timer task.

It does not interrupt the task that is currently being executed if
there is any, nor waits for the scheduler thread to finish.

Main concern here is that any task that is scheduled must complete
before you shut down WebappClassLoader.


> - 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.

Yes. That is what happens.

> 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.

At least you may do a Thread.yield() to let that other thread a chance
to run (and finish).


I wonder whether WebappClassLoader#clearReferencesStopTimerThread()
can be improved to check whether the value of newTasksMayBeScheduled
flag is already false. It does not solve the issue of a task that is
being run at this very moment, though.

Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message