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
>=20
> Hi, Pid-
>=20
> For the sake of clarity, I'll repeat this here:
>=20
> 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 =3D=3D null )
> {
> Calendar firstRunTime;
>=20
> timer =3D new Timer( true );
> timerTask =3D new ATimerTask();
>=20
> firstRunTime =3D new GregorianCalendar();
> firstRunTime.set( Calendar.HOUR_OF_DAY, 12 );
> firstRunTime.set( Calendar.MINUTE, 0 );
> firstRunTime.set( Calendar.SECOND, 0 );
> firstRunTime.set( Calendar.MILLISECOND, 0 );
>=20
> timer.scheduleAtFixedRate(
> timerTask, firstRunTime.getTime(), 1000 * 60 * 60 * 24 =
);
> }
> }
>=20
> public void contextDestroyed( ServletContextEvent sce )
> {
> if ( timer !=3D null )
> {
> timer.cancel();
> timer.purge();
>=20
> timer =3D null;
> timerTask =3D null;
>=20
> try
> {
> Thread.sleep( 1000 );
> }
> catch ( InterruptedException ie )
> {
> }
> }
> }
> }
>=20
> 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?
> 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?
p
> The InterruptedException is caught and logged if it occurs. I've never=
> seen it in the logs.
>=20
> Thanks.
>=20
> -Terence
>=20
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>=20
|