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

Reply via email to