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 <brianbr...@gmail.com> wrote: > 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 >> >> >
