Pid, On 7/14/2011 11:25 AM, Pid wrote: > On 14/07/2011 16:11, Pid wrote: >> On 14/07/2011 15:23, Christopher Schultz wrote: >>> All, >>> >>> Is there any interest in having a configuration option for WCL that >>> allows certain thread names to be ignored during webapp shutdown? >>> >>> See http://markmail.org/message/vqeeyosbqxq3tim6 for a short discussion. >>> >>> It appears that there may sometimes be a race condition where the webapp >>> can't force the termination of an app-started thread that *will* >>> eventually shut down. A minor change could alleviate printing a warning >>> message on redeploy that may worry admins. >>> >>> I'm sure this would be useful to Terence, but I'm not sure if there's >>> wide applicability. >> >> Why does this help? AFAICS he's not stopped the thread, he's just >> stopped the scheduler. If he wants the thread to stop he'll have to hit >> .cancel() on the task. > > Actually, that might not be true. (Teach me to skim the docs). > > > The OP is really reporting that the timer.cancel() method doesn't block > & wait for all the running timer task threads to finish.
He's properly shutting-down the task scheduling service and all the tasks finish before his code continues. The problem is a race condition between the termination of the worker threads and the thread-checking code in Tomcat. > Interrupting a timer task thread might not be possible without jumping > through hoops; the OP reports that if the run method is empty, there's > no problem - but this would be expected because the run() cycle would be > short & therefore the timer task thread will win the race between > contextDestroyed completing & the thread finishing. I thought he said that, with an empty run method, he still needs to call sleep() in order to avoid the race condition. > If the thread takes longer (the OP reports ~0.5s) then > contextDestroyed() wins and Tomcat reports threads down. > > Quartz suffers from the same problem (or did last time I looked). The problem is that the OP can't get ahold of the Thread objects themselves in order to do a join() on them. All tasks are cancelled, successfully. His hands are tied by the API. I'm trying to avoid the following progression: 1. TaskScheduler has a race condition, triggers a false alarm in Tomcat 2. IT staff, etc. are directed to ignore Tomcat warnings about threads 3. Tomcat starts reporting legitimate thread problems 4. Everyone ignores them because they have been directed to do so My proposal is to be able to identify which threads have been determined to be non-threatening, and suppress the warning. -chris
signature.asc
Description: OpenPGP digital signature
