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