Hi Terence, I will try that. Thanks!
On Sat, Jul 30, 2011 at 3:13 PM, Terence M. Bandoian <tere...@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<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.** > 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<users-unsubscr...@tomcat.apache.org> > For additional commands, e-mail: users-h...@tomcat.apache.org > >
