tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Terence M. Bandoian" <>
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 20:13:32 GMT
  On 1:59 PM, Brian Braun wrote:
>>> 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:
>>> - 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.
> Oh, I forgot to mention that before I cancel() the timer, I iterate on all
> the tasks and cancel them. I guess that guarantees that everything has
> finished.
>>> - 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).
> How to I get a reference to the timerThread?
>> 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:
>> For additional commands, e-mail:
>> 2011/7/30 Brian Braun<>:

Hi, Brian-

As Kris Schneider suggested, I ended up using 
Executors.newSingleThreadScheduledExecutor() instead of a Timer.  See 
the last post in the thread Konstantin referenced 
(, dated July 24, for 
example code.  It appears to work reliably.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message