Timer.cancel()....What it does?

[pradeep chellappan]

Hi,
I am trying to replicate a timeout scenario.I am using Timer class.Please find the program below:

import java.util.* ;
public class MainProgram {
public static void main(String args[]) {

SubProgram sp = new SubProgram() ;
Timer t = new Timer() ;
try{
t.schedule(sp,0);
Thread.sleep(50);
t.cancel();
}catch(Exception e){
e.printStackTrace() ;
}
if (sp.b)
System.out.println("Successfull.....") ;
else
System.out.println("Not Successfull.....") ;

}


}
class SubProgram extends TimerTask {
boolean b = false ;
public void run() {
try{
Thread.sleep(100) ;
System.out.println("After 100") ;
b = true ;
}catch(Exception e){
e.printStackTrace() ;
}
}


}
Question:
---------

1. In the above scenario,the main thread will wait for 50 millisec...and then it will cancel the timer.My question is:
a) What happens to the new timer thread that is spawned, when it executes the run method for more than 50 sec...(here in the code it sleeps for 100 ms).Will the thread also gets killed after 50 sec along with the cancelling of the task?
b) What happens to the new timer thread that is spawned, when it executes the run method and gets hanged.Will the thread also gets killed after 50 sec along with the cancelling of the task?

Thanks in advance.
Pradeep.

[Nitesh Kant]

This is what the javadoc for Timer.cancel has to say:

Terminates this timer, discarding any currently scheduled tasks. Does not interfere with a currently executing task (if it exists). Once a timer has been terminated, its execution thread terminates gracefully, and no more tasks may be scheduled on it.

Note that calling this method from within the run method of a timer task that was invoked by this timer absolutely guarantees that the ongoing task execution is the last task execution that will ever be performed by this timer.

This method may be called repeatedly; the second and subsequent calls have no effect.

It clearly says that the currently executing task is not touched. This means that the timer will not worry about the executing task(even if it hangs, crashes, burns, etc...) but will not schedule any more tasks after this call.
Its always nice to read the javadocs for the java classes as in most of the cases it will give a fair idea about what the method/class/package is supposed to do.
[ April 17, 2007: Message edited by: Nitesh Kant ]

[pradeep chellappan]

Hi Nitesh,
Appreciate your reply.Thanks for your time.
If you could answer my 2 questions with your supportings then i could understand the scenario better,that's the reason why i posted the code.I am concerned mainly with the new thread that is spawned against various negative scenario like hanging,not returing etc...
Thanks in Advance.
Pradeep

[Ulf Dittmer]

What is the point of cancelling the timer? You do want it to run, and to actually finish execution, right?

[Nitesh Kant]

In both of the scenarios that you have mentioned, the spawned thread will keep on executing and will not be interupted by the timer.
Ulf,
The cancellation of timer may be required in the case, where the user does not want to execute any new tasks submitted to this timer.
[ April 17, 2007: Message edited by: Nitesh Kant ]

[Ulf Dittmer]

Ulf,
The cancellation of timer may be required in the case, where the user does not want to execute any new tasks submitted to this timer.

What I was getting at is that, since this is a one-time execution, it does not make sense to use it here.

Furthermore, instead of "t.schedule(sp,0);" and a "Thread.sleep(100)" in the TimerTask, it should be "t.schedule(sp, 100)", which will make things simpler.

[Nitesh Kant]

Originally posted by Ulf Dittmer:

What I was getting at is that, since this is a one-time execution, it does not make sense to use it here.

Furthermore, instead of "t.schedule(sp,0);" and a "Thread.sleep(100)" in the TimerTask, it should be "t.schedule(sp, 100)", which will make things simpler.

I assumed that this is just a sample code to create a stage for the questions that followed!!
If this was not the case then that code doesn't really make any sense.

[pradeep chellappan]

Hi Nitesh/Ulf ,
Thanks for the responses.
My intention of the sample program is to spawn a thread from the main thread and let the main thread to wait for some time(say 50 ms) for the child thread to do a particular task(say within 30 ms).
If in case,the child thread(timer thread) which is spawned using t.schedule(sp,0) as in my code,gets hung,i want the thread (timer thread)to be killed,which i suspect is not happening as per my code.
Also,consider another scenario,if the main thread sleeps for say 50 ms and if the timer thread sleeps for 60 ms ,then i would like to kill, the timer thread exactly when 50 ms is over.This is not happening as per my code.Ulf,it is for this reason that i used t.schedule(sp,0) & sleep(<millisec> .But it didn't help my cause.My implemetation is not killing the timer thread nor canceling the thread as Nitesh has pointed out.I don't want this to happen.My intention is to cancel the timer and kill the timer thread and also their is constraint that main thread can wait only for this much period.
Can you guys direct me with any modifications that i can do with my code or suggest any other alternative approach for achieving this task.

Advanced Thanks.
Pradeep.

[Nitesh Kant]

I think i am not getting the motive behind this requirement. If your business requirements are guiding it then i think you should think of an alternative way(since i dont know the business reason, i cant comment.)
A few other reasons that i can think of:
1) You are creating a framework, where you want to monitor thread activity and do not allow a thread to process for more than a defined time. I think this is not the correct thing to do as you would never know at what stage of processing the thread will be and to kill it(even though i dont know a way to do that) will not be sensible.
2) You want to guard against blocked threads(waiting for I/O or monitor). If this is the intention then only a wait can be interrupted and not an I/O block.

I think the only graceful way is to set a flag on the thread object to stop processing and let the thread check this flag at regular intervals.

If you want to guard against a thread getting hung, then it is a better idea to modify the processing code in the thread rather than leaving on to someone else to monitor it.