I am using a ScheduledThreadPoolExecutor which runs a ScheduledFuture every x (currently 100) msec . The task takes just a couple of msec to execute.
Trying to cancel it and interrupt possibly running tasks, by calling future.cancel(true), I observe that although the future shall terminate, the task is still executed, causing program errors. From my log output it seems that the cancelling takes place during the last execution, but cancelling it does NOT interrupt the Thread, instead it is allowed to run till its end. Also this last execution takes several times longer than the previous ones. This behaviour is reproducible but does not happen always.
To my knowledge cancelling shall immediately call interrupt() in my thread, giving me the option to react accordingly?? The weird thing is that if I artificially extend the task duration by sleeping some time at the end of run(), the interruption happens as I expected.
Does anyone have an explanation for this behaviour? Since it seems to be depending on the task duration I thought about maybe there is some weird heuristic implemented in the executor service to plan the execution schedule which is going wrong. Is there any other (smarter) way the handle the problem?
To my knowledge cancelling shall immediately call interrupt() in my thread, giving me the option to react accordingly?? The weird thing is that if I artificially extend the task runtime by sleeping some time at the end of run(), the interruption happens as I expected.
If you interrupt a thread, it basically sets a flag. If you don't check this flag, or call something which does, nothing happens as you have seen. Thread.sleep() does check, but you can check yourself with Thread.currentThread().isInterrupted();
Is there any other (smarter) way the handle the problem?
Write your code so the task checks whether it should still do something. I wouldn't rely on interrupt alone to do this. BTW Some third party libraries incorrectly consume an interrupt or handle them in ways you might not expect.
Related
I want to terminate(or abort) a task immediately when it is running, not to wait its ending. I search in JDK, the Timer class and the TimerTask class not satisfied, their cancel method is not proper for me, for the task will contiue to execute util it finish, but I want to stop it immediately.
What should I do? I serach for Spring and Quartz, but no good idea...
This is not something that is recommended to do in a multi threaded environment as it can break your code in all sorts of ways. For example imagine you are half way through changing something and suddenly your thread gets killed leaving it in a half-modified state. Because it is not recommended no easy way is provided to do it.
The correct way to do this is to use a Thread and interrupt it.
http://docs.oracle.com/javase/tutorial/essential/concurrency/interrupt.html
Inside your Thread code you can check isInterrupted() at times where it would be appropriate to abort and abort, but the abort is controlled by the running thread which is the only thing that knows when it is safe to do so.
The ScheduledExecutorService also allows you to work with a ScheduledFuture and cancel that, which then works in the same way as interrupting the thread does.
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#cancel(boolean)
So I have some code, I am creating 6 threads, in my main thread, that run some code. I start the threads. I then call join() on the threads, so that the main thread waits for them all to die before continuing with execution.
Now, I am using some really basic and most likely inaccurate way to measure how long my code takes to run. Just calls to get the system time at the start, the end, and then print the difference.
Lets say it is taking, for example, around 500ms to run all of my code.
I decided to remove the calls to join() for each thread, and instead I just told my main thread to sleep for 20ms. This resulted in my code finishing in around 200ms, and the main thread managed to continue with execution with the proper data from the worker threads - i.e. the 6 worker threads must have finished in that 20ms wait.
THEREFORE, why is it taking so much longer when I use .join on each worker thread? Naturally, I cannot keep the call in the main method to sleep(20), and would rather use something like join()'s
The problem with multi-threaded bugs is you can appear to be working when it is not working reliably. It is possible your threads are doing something you don't need at the end, or you joining thread doesn't use the results right away. In any case, I suggest you wait for the result correctly.
BTW I would use an ExecutorService as this allows you to recycle your threads and wait for just the results you need in the form of a Future<MyResult> note this also captures and Exception/Error thrown as well.
It is also possible that your code is simply not getting finished if you take out the joins. If your main function exits without joining on all of its threads, then it is possible some are getting set as daemon threads via setDaemon(), which would stop the program cleanup from waiting on them.
Do you own all the code involved?
I'm trying to implement a sort of interrupt process into my java program so that if an operation takes longer than 5 minutes, i can kill it.
Is there any sort of generic way I can do this? I'm using an external API to carry out very processor intensive calculations and it already multithreads the process so can I still use the executor class to do this?
-edit-
Ended up solving it by using a bash script wrapper function. It kills the PID after a timeout.
It's considered unsafe to kill or forcefully stop a Thread because it may leave the program in an undetermined state, which will later cause a crash or other more serious problem. Instead, you should design your worker thread to periodically check the interrupt flag via Thread#isInterrupted or Thread#interrupted and exit if it is set. Then, using another thread, you can signal to the worker thread that it should stop by calling interrupt() on the worker thread, which will result in the worker thread detecting the interrupt or possibly receiving an InterruptedException if it is blocking inside your code or the third party code.
Depending on how your thread is coded (ie. whether it would properly terminate when interrupted), you could use the provided Thread.join(millis) or Thread.join(mills, nanos) method calls.
Something like this:
Thread myThread
// ... start myThread
myThread.join(300000); // 5mins in millis
if (myThread.isAlive()) {
myThread.interrupt();
}
Inside the thread itself, you would want to ensure that you .yield() at relevant points and properly handle an InterruptedException to allow this kind of logic to work.
Of course this is an "ideal" kinda situation - if the thread is blocked due to some outside process, and cannot handle the .interrupt(), then it will not work very well.
HTH
I need to force the release of resources when a task is interrupted. For that, I implemented this solution. But with this, when I call shutdown() all the task in the ScheduledThreadPoolExecutor.getQueue() are forced correctly, but some of my jobs kept the resources. I checked very well the behavior and I figured out this: when a task is in execution, he is not present in the ScheduledThreadPoolExecutor queue (I know it sounds obvious). The problem is that I need to force the release of resources for all the jobs (in the queue or in execution)
So, How can I get the jobs that are in execution? Do you have a better idea?
You can maintain a list of all the Future's you create when you submit the jobs.
Use this list to cancel all futures.
Don't you want to call
executor.shutdownNow()
that will attempt to cancel currently running tasks (using Thread.interrupt so you'll need to implement an 'interruption policy' in each task that uses the interrupt flag).
from the javadoc
Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution.
There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. For example, typical implementations will cancel via Thread.interrupt, so any task that fails to respond to interrupts may never terminate.
This will return a list of waiting tasks, so you can always put this back onto a 'wait list' rather than loose them completely. You might also want follow that up with an 'await termination' to avoid run away code. For example, executor.awaitTermination(...).
tempus-fugit has some handy classes for handling this. You just call
shutdown(executor).waitingForShutdown(millis(400));
see here for details.
Also, the solution you outline in the blog post; I'm not sure if that's quite right. Future.cancel will only stop the task from being scheduled. If you were to update the example in the blog to allow interruption (ie cancel(true), it'd be equivalent (more or less) with the shutdownNow. That is to say, it will call interrupt on the underlying task which (if you've implemented an interruption policy) will stop it processing. As for cleaning up after interruption, you just need to make sure that you handle that appropriately within the interruption policy implementation. The upshot is that I think you can cancel and cleanup correctly using shutdownNow (or cancel(true))
I want to know how to stop a specified function's execution within a specified time in java.
For example: I may call a function called print_data(). If it takes more time to execute, I will have to stop that function's execution.
Is it possible to stop the execution like this?
Thanks in advance
You could add some checks to your function: save the timestamp when function started working and then periodically checking that inside the function, throwing an exception if function takes too long.
This is the cleanest way to accomplish such task in Java.
There is no safe way to stop a thread executing, unless it is being cooperative; e.g. it regularly checks the 'interrupted' flag.
#BobbyShaftoe suggests this in a comment:
You could execute this function in a separate thread and then abort the thread after some period of time.
This is misleading and dangerous advice. The only way to "abort" a thread is to use the deprecated Thread.stop() method. If you look at the javadoc for that method you will see that it is a fundamentally dangerous method that is liable to have undesirable and unpredictable side-effects.
It should also be noted that #tonio's solution doesn't stop the function's execution. It simply stops waiting for the function's execution to finish. The function could continue executing indefinitely, chewing up resources to no good effect.
You can use the TimeUnit enum from java.util.concurrent, in particular the timedJoin method.
You specify a time to wait, and a thread. timedJoin will let your thread execute until termination, or stop if the processing takes more time than the timeout allowed. You can use an anonymous class to wrap your method in a Thread object easily.
This can be as easy as:
SECONDS.timedJoin(
new Thread() {
public void run() {
print_data();
}
},
10);
for a 10 seconds timeout.