I have written a task to send a certain TCP message through a socket. I have a file with a bunch of messages and some timestamps, so I programmed the task as a TimerTask, and I scheduled it with a Timer with the first message timestamp.
When it finishes, the task run method is over, but its associated thread remains, it's not cancelled. If I try to reschedule the task with a new Time, I'm getting an exception telling me that I cannot reschedulle a schedulled or cancelled task.
I also tried cancellig it before rescheduling, but obviously, as the exception told, it remains the same problem.
I can't schedule the task with a constant perior to let it repeat itself, because each message has a time and it is not constant.
How can I reschedule the TimerTask? And by the way, is there any way of waiting for the task to end, just as in socket communications when it blocks with ready method until a message arrives?
A TimerTask is not designed to be rescheduled and it is the Timer that manages the (single) thread.
Use one Timer and many new TimerTasks:
Corresponding to each Timer object is a single background thread that is used to execute all of the timer's tasks, sequentially ..
After the last live reference to a Timer object goes away and all outstanding tasks have completed execution, the timer's task execution thread [should] terminates gracefully (and becomes subject to garbage collection).
[From each of the schedule methods:]
Throws IllegalStateException if [the TimerTask] was already scheduled or cancelled, timer was cancelled, or timer thread terminated.
If there are indeed many threads spawned by a single Timer, then that would be a bug which is unlikely: make sure there really is only one Timer object being used.
The last question, of how to compose individual events into a workflow, should be a separate post.
Related
I am considering an implementation of an ExecutorService to run a series of tasks. I plan to use the internal queue to have a few tasks waiting for their turn to run. Is there some way to interrupt the task (the Runnable) that is currently running in an ExecutorService thread, and keep the thread alive to run the next task? Or is only possible to call .shutdown() and then create a new ExecutorService?
I have found this and wanted to know if there are any other solutions.
Instead of interfering with the threads you may want to have a Task class (that extends or wraps the Runnable) which implements an interrupt mechanism (e.g. a boolean flag).
When you execute your task you need to check this flag periodically and if it is set, the task should stop what it is doing. You might want to return a specific result at this point, that tells your code that the task was cancelled succesfully.
If a user now decides that he no longer requires the results from this task,
you will have to set this flag. However the task might have already completed at this point of time so you still need to deal with the cases where the result already exists but the user does no longer care about it.
An interrupt on a thread level does not guarantee that the thread stops working. This will only work if the thread is in a state where it can receive an interrupt.
Also you should not interfere with the Threads of the ExecutorSerivce directly, as you might unintentionally stop a different task or stop the ExecutorSerivce from working properly.
Why would you want to kill that task and continue with the next one? If it is a question of times you can define that the threads that are taking longer than you declared in the method that executes them are automatically canceled. E.g:
ExecutorService executor = Executors.newSingleThreadExecutor();
executor.invokeAll(Arrays.asList(new Task()), 60, TimeUnit.SECONDS); // Timeout of 60 seconds.
executor.shutdown();
If any of the threads takes longer than 60 seconds it will throw a cancellation.Exception() that you must catch
With GcmNetworkManager, my understanding is two tasks with same tag can never run concurrently. This is according to documentation here
Per service, two tasks with the same tag will never execute
concurrently. Should a newly-scheduled task arrive while an existing
task is still running, the new task will be dropped. In addition,
different tasks may be scheduled concurrently, each invoked in a
separate thread, if their schedules overlap. It is up to you to ensure
thread safety when scheduling multiple tasks.
My question is:
If we schedule a task (a OneoffTask):
Task myTask = ... ;// create task of MY_TAG
gcmNetworkManager.schedule(myTask);
Then at some point later on we cancel it but let's assume it's currently running (its GcmTaskService:onRunTask is still running on its thread):
// Cancel task
// At this point GcmTaskService:onServiceRun could still be running (on a different thread)!
// `GcmTaskService:onRunTask` will continue to run
gcmNetworkManager.cancelTask(MY_TAG, ..);
and then at another time later on, we re-schedule same tag:
// Re-schedule task.
// At this point GcmTaskService:onRunTask could still be running (on a different thread)!
Task myTask = ... ;// create task of MY_TAG
gcmNetworkManager.schedule(myTask);
when time comes to run GcmTaskService:onRunTask for the re-scheduled task, does GcmNetworkManager still knows there is a task running (GcmTaskService::onRunTask() hasn't returned? (Note that at this point its tag was cancelled)
Or does it actually starts a new GcmTaskService and callGcmTakService:onRunTask because its tag was cancelled?
Which means there could actually be two GcmTaskService:onRunTask running at same time for same tag.
I am using a TimerTask to run some periodic tasks, the task being processing a set of files. I have a requirement where if the number of files to be processed exceeds a pre-determined limit, the thread suspends execution and waits till the next cycle to start processing the files again. Is there a way to suspend the TimerTask until the next execution period or do I have to extend the TimerTask class to achieve this functionality? I saw there is a TimerTask.cancel method, but this will cancel all further executions of this thread. I don't want this to happen. I just want the thread to be suspended until the next execution period. I don't have the luxury of moving to any of the other concurrent classes in Java as our framework uses TimerTask, and I have to stick with it.
Any suggestions, pointers or tips are greatly appreciated.
thanks,
Asha
One approach would be to put the tasks on a BlockingQueue and let the TimerTask remove() and process entries until the queue is empty or the pre-determined limit has been reached. Any remaining entries will be in the queue waiting for the next scheduled execution.
I have a task that needs to be executed on a schedule. (It basically polls a database looking for a change and then executes code depending on the result). The problem is that I need the polled task to happen even when it is already executing.
So far I have tried using a Timer/TimerTask combo with the scheduleAtFixedRate() method and the ScheduledThreadPoolExecutor/Thread combo with the scheduleAtFixedRate() method.
Both wait for the current scheduled task to complete before running the next. I need to be able to schedule a task to run every 5 seconds and have it run even if the last execution of the task has not yet completed.
Any ideas?
How about using one Timer as the "kick-off" timer, but then a separate thread pool for execution: when the timer ticks, you submit the task to the thread pool for immediate execution. (You may want to tweak the thread pool to have some maximum number of tasks running simultaneously.)
new Timer(...).schedule(task)
Is task guaranteed to be run by a single thread at any given time?
From the Javadoc
Corresponding to each Timer object is a single background thread that is used to execute all of the timer's tasks, sequentially. Timer tasks should complete quickly. If a timer task takes excessive time to complete, it "hogs" the timer's task execution thread. This can, in turn, delay the execution of subsequent tasks, which may "bunch up" and execute in rapid succession when (and if) the offending task finally completes.
So, yes, you get a new Thread (separate from the caller's thread). Every task in that timer shares the same thread.
There is a single thread per Timer, so the answer to your question is yes
Indeed. They all run on a same background thread corresponded to the Timer object in sequence. BUT two different Timer instances will run (I believe) on different threads, so you have to save reference to a timer object to schedule more tasks sequentialy.