You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Brian Braun <br...@gmail.com> on 2011/07/30 03:36:35 UTC
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"
Hi,
I'm using Tomcat 7.0.11 and I'm experiencing a leak problem.
This is what I find in the log:
Jul 29, 2011 7:36:51 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesJdbc
SEVERE: The web application [/admin] registered the JDBC driver
[com.mysql.jdbc.Driver] but failed to unregister it when the web application
was stopped. To prevent a memory leak, the JDBC Driver has been forcibly
unregistered.
Jul 29, 2011 7:36:51 PM org.apache.catalina.loader.WebappClassLoader
clearReferencesThreads
SEVERE: The web application [/admin] appears to have started a thread named
[ParadiseManualzoneTimer] but has failed to stop it. This is very likely to
create a memory leak.
Jul 29, 2011 7:36:55 PM org.apache.catalina.core.StandardContext reload
INFO: Reloading Context with name [/admin] is completed
Regarding the JDBC driver, I understand that the Tomcat mechanism to solve
the leaks is able to unregister it, so for now I want to concentrate in the
other leak, later I will get back to this and find the way to solve it.
Regarding the thread, it belongs to a java.util.Timer. It is a timer that I
create in the contextInitialized() method of my app, and I attach 3 tasks to
it (java.util.TimerTask). These tasks work great during the live of the app.
In the contextDestroyed() method I do this:
//Cancel tasks
LinkedList<java.util.TimerTask> tasks=
(java.util.LinkedList<java.util.TimerTask>)(contexto.getAttribute("TASKS"));
Iterator<java.util.TimerTask> taskIterator =tasks.iterator();
while (taskIterator.hasNext())
{
java.util.TimerTask task =taskIterator.next();
task.cancel();
}
contexto.removeAttribute("TASKS");
taskIterator=null;
tasks=null;
//Destroy Timer
java.util.Timer
timer=(java.util.Timer)contexto.getAttribute("TIMER");
contexto.removeAttribute("TIMER");
timer.cancel();
timer=null;
I think I'm doing the right thing, but it seems that the thread stays in the
JVM. Im using "Yourkit" (a very powerful profiler!) and I clearly see that
thread.
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?
Thanks in advace!
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"
Posted by Brian Braun <br...@gmail.com>.
(I have just found the archive, sorry for asking something so silly)....
On Sat, Jul 30, 2011 at 9:21 AM, Brian Braun <br...@gmail.com> wrote:
> Hi,
> Where do I find that? is there an archive of the threads?
> Thanks!
>
>
>
> On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko <
> knst.kolinko@gmail.com> wrote:
>
>> 2011/7/30 Brian Braun <br...@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
>>
>>
>
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"
Posted by Brian Braun <br...@gmail.com>.
Hi,
Where do I find that? is there an archive of the threads?
Thanks!
On Sat, Jul 30, 2011 at 9:14 AM, Konstantin Kolinko
<kn...@gmail.com>wrote:
> 2011/7/30 Brian Braun <br...@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
>
>
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"
Posted by Brian Braun <br...@gmail.com>.
Finally I have found something interesting: Tomcat has been warning me about
the TimerThread, saying that it could bring leaks. And the "Find Leaks"
button in the Tomcat Manager actually has been telling me that I do have
leaks, because it notices that the class loader can't be garbage collected.
But the condiction that made the class loader to be unable to unload was not
actually the TimerThread, but another object that I created, that references
some cryptografic libraries! I just found out that, solved it, and now its
clean of leaks! I have even restarted the app a lot of times, and not only
the Tomcat manager says its clean of leaks, but also the Yourkit profiler
shows noe just one object of the class loader!
:-)
On Sat, Jul 30, 2011 at 3:28 PM, Brian Braun <br...@gmail.com> wrote:
> Hi Terence, I will try that. Thanks!
>
>
>
>
> On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian <te...@tmbsw.com>wrote:
>
>> 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:
>>>> http://markmail.org/thread/**oph2acjbdptcvduf<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.
>>>>
>>>>
>>>> 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: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
>>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>>
>>>> 2011/7/30 Brian Braun<br...@gmail.com>:
>>>>
>>>
>> Hi, Brian-
>>
>> As Kris Schneider suggested, I ended up using Executors.**
>> newSingleThreadScheduledExecut**or() instead of a Timer. See the last
>> post in the thread Konstantin referenced (http://markmail.org/thread/**
>> oph2acjbdptcvduf <http://markmail.org/thread/oph2acjbdptcvduf>), dated
>> July 24, for example code. It appears to work reliably.
>>
>> -Terence
>>
>>
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
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"
Posted by Brian Braun <br...@gmail.com>.
Hi Terence, I will try that. Thanks!
On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian <te...@tmbsw.com>wrote:
> 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:
>>> http://markmail.org/thread/**oph2acjbdptcvduf<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.
>>>
>>>
>>> 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: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>> 2011/7/30 Brian Braun<br...@gmail.com>:
>>>
>>
> Hi, Brian-
>
> As Kris Schneider suggested, I ended up using Executors.**
> newSingleThreadScheduledExecut**or() instead of a Timer. See the last
> post in the thread Konstantin referenced (http://markmail.org/thread/**
> oph2acjbdptcvduf <http://markmail.org/thread/oph2acjbdptcvduf>), dated
> July 24, for example code. It appears to work reliably.
>
> -Terence
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.**apache.org<us...@tomcat.apache.org>
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
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"
Posted by "Terence M. Bandoian" <te...@tmbsw.com>.
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:
>> 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.
>>
>>
> 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: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>> 2011/7/30 Brian Braun<br...@gmail.com>:
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
(http://markmail.org/thread/oph2acjbdptcvduf), dated July 24, for
example code. It appears to work reliably.
-Terence
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
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"
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/30 Brian Braun <br...@gmail.com>:
>>
> 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.
It does not guarantee anything for the task that is currently being run.
If you look at the Javadoc for TimerTask.cancel():
"(If the task is running when this call occurs, the task will run to
completion, but will never run again.)"
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
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"
Posted by Brian Braun <br...@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.
>
>
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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
> 2011/7/30 Brian Braun <br...@gmail.com>:
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"
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/30 Brian Braun <br...@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
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"
Posted by Brian Braun <br...@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:
- 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
<kn...@gmail.com>wrote:
> 2011/7/30 Brian Braun <br...@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
>
>
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"
Posted by Konstantin Kolinko <kn...@gmail.com>.
2011/7/30 Brian Braun <br...@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