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"

[Brian Braun]

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  wrote:

> Hi Terence, I will try that. Thanks!
>
>
>
>
> On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian 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

  - 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-h...@tomcat.apache.org

 2011/7/30 Brian Braun:

>>>
>> 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 ), 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-h...@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"

[Brian Braun]

Hi Terence, I will try that. Thanks!



On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian 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
>>>
>>>  - 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-h...@tomcat.apache.org
>>>
>>> 2011/7/30 Brian Braun:
>>>
>>
> 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 ), 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-h...@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"

[Terence M. Bandoian]

 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

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 
(http://markmail.org/thread/oph2acjbdptcvduf), dated July 24, for 
example code.  It appears to work reliably.


-Terence


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@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"

[Konstantin Kolinko]

2011/7/30 Brian Braun :
>>
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@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"

[Brian Braun]

> > 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@tomcat.apache.org
>
> 2011/7/30 Brian Braun :

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"

[Konstantin Kolinko]

2011/7/30 Brian Braun :
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@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"

[Brian Braun]

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
wrote:

> 2011/7/30 Brian Braun :
> > 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@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"

[Brian Braun]

(I have just found the archive, sorry for asking something so silly)



On Sat, Jul 30, 2011 at 9:21 AM, Brian Braun  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.koli...@gmail.com> wrote:
>
>> 2011/7/30 Brian Braun :
>> > 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-unsubscr...@tomcat.apache.org
>> For additional commands, e-mail: users-h...@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"

[Brian Braun]

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
wrote:

> 2011/7/30 Brian Braun :
> > 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-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: users-h...@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"

[Konstantin Kolinko]

2011/7/30 Brian Braun :
> 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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org