On 1:59 PM, Pid wrote:
> On 14/07/2011 06:05, Terence M. Bandoian wrote:
>> On 1:59 PM, Pid wrote:
>>> ATimerTask is a private instance in AServletContextListener, is this
>>> necessary and if so, why?
>>>
>>> What logic is contained in ATimerTask?
>>>
>>> Are you overriding TimerTask.cancel() and do you catch
>>> InterruptedException?
>>>
>>>
>>> p
>> Hi, Pid-
>>
>> For the sake of clarity, I'll repeat this here:
>>
>> public class AServletContextListener implements ServletContextListener
>> {
>> private Timer timer;
>> private ATimerTask timerTask;
> Yes, but why is the timerTask an instance field? Put another way, why
> is there a reference to it outside of the contextInitialized() method?
>
>
>> public void contextInitialized( ServletContextEvent sce )
>> {
>> if ( timer == null )
>> {
>> Calendar firstRunTime;
>>
>> timer = new Timer( true );
>> timerTask = new ATimerTask();
>>
>> firstRunTime = new GregorianCalendar();
>> firstRunTime.set( Calendar.HOUR_OF_DAY, 12 );
>> firstRunTime.set( Calendar.MINUTE, 0 );
>> firstRunTime.set( Calendar.SECOND, 0 );
>> firstRunTime.set( Calendar.MILLISECOND, 0 );
>>
>> timer.scheduleAtFixedRate(
>> timerTask, firstRunTime.getTime(), 1000 * 60 * 60 * 24 );
>> }
>> }
>>
>> public void contextDestroyed( ServletContextEvent sce )
>> {
>> if ( timer != null )
>> {
>> timer.cancel();
>> timer.purge();
>>
>> timer = null;
>> timerTask = null;
>>
>> try
>> {
>> Thread.sleep( 1000 );
>> }
>> catch ( InterruptedException ie )
>> {
>> }
>> }
>> }
>> }
>>
>> It isn't absolutely necessary but why would I make the ATimerTask
>> reference anything but private?
> As above.
>
> The only reason to keep a handle on the task itself is if you're calling
> cancel on the task - but you aren't doing that. Maybe you should?
>
You're right, there's no reason for the ATimerTask reference to be a
instance variable. I did try canceling the tasks individually before
canceling and purging the timer but it made no difference.
>> The timer tasks in the application perform some very straightforward
>> database and file system maintenance when their run methods are invoked
>> that might take up to half a second each. None override the cancel
>> method. All are scheduled to execute on a daily or weekly basis and
>> none at even close to the same time of day.
> The timer.cancel() method doesn't interrupt or stop a running task
> immediately, it just prevents it from running again.
>
> Your timer creates as daemon threads - perhaps you could assign a name
> too, and then report (just for confirmation) that it is the expected
> thread name(s) Tomcat's complaining is still running?
>
>
>> Also, while testing for ways to prevent the error message from being
>> written to the logs, I commented out the run method bodies of the timer
>> tasks so that they returned immediately and, given that I know the
>> schedule, none of the timer tasks were executing when I stopped or
>> restarted Tomcat.
> That reads (to me) like you're saying that if you comment out the run
> methods, everything is OK. Is this correct?
When I comment out the run method bodies, I still get the error message
in the logs unless I insert the call to Thread.sleep.
Thanks again.
-Terence
>
> p
>
>> The InterruptedException is caught and logged if it occurs. I've never
>> seen it in the logs.
>>
>> Thanks.
>>
>> -Terence
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
|