I have a Spring Boot application that uses a #Scheduled annotation with a fixed delay. The annotation is used in different classes with different delays. However, at midnight every day all scheduled tasks stop running.
Does anyone know why this might be happening? I can't find any explanation online.
(I am using version 2.0.2.RELEASE of Spring Boot and 5.0.6.RELEASE of Spring Core.)
Thanks in advance!
I'm not sure what do you mean about stopping running.
But the first work you need to do is starting your schedules on different threads and put them into a queue.
If stopping means suspending for a while,then you create a new schedule that make other schedules sleep some time at midnight.Maybe the new schedule should have be started when the thread are sleeping,and the way to prevent is to make sure only one schedule(I mean same kind of schedule) could be put in the queue at the same time.
If you just mean kill all other schedule at midnight,you just need to start your midnight schedules and kill others.
So sorry about my poor English,hope this could help you.
#Scheduled(fixedDelay = 1000)
void scheduleFixedDelayTask() {
System.out.println(
"Fixed delay task - " + System.currentTimeMillis() /
1000);
}
In this case, the duration between the end of last execution and the start of next execution is fixed. The task always waits until the previous one is finished.
This option should be used when it’s mandatory that the previous execution is completed before running again.
So maintain the delay such a way that the previous execution completed.
Hope it helps.
Thanks to everyone who replied.
As it turns out, this was not an issue with Spring. It appeared the tasks stopped because the logs stopped. What really happened was that our scripts that tail the logs were not smart enough to handle log files that roll at midnight (face palm).
Related
I'm using spring-boot #Scheduled annotation with fixedDelay in milliseconds as documented in javadoc:
Execute the annotated method with a fixed period in milliseconds between the end of the last invocation and the start of the next.
Code:
#Scheduled(fixedDelay=1000)
public void task() {
LOG.info("START: " + System.currentTimeInMillis());
....do some work here...
LOG.info("END: " + System.currentTimeInMillis());
}
And sometimes I get such output that time between previous task end and next task starts is less than 1000ms for about 2-30 milliseconds.
Is it normal due to some granularity or why is it happening? Is there any guaranties about this delta value?
There are different ways in which you can use #Scheduled annotation.
According to the documentation:
The fixedRate invokes the method every t ms but the time delay is measured from the start of the invocation. If t ms are passed and the method is still in execution then the next invocation will wait for it to finish and will invoke right after the first one. Try putting Thread.sleep(3000) in your method. I think that your method is taking about 950ms to complete.
If you want to wait after finishing the execution you can use fixedDelay.
Obviously it cannot be guaranteed since you're most likely not on a real time system. Depending on what the CPU(s) do at the moment it can vary like that. It's quite hard to do something like that actually on most PC's due to the OS scheduling calls and so on (unless you have direct access to the CPU/GPU but even then)
How #Scheduled(fixedDelay=1000) works is, it will run this void method every 1000 ms(If this task finish execution < 1000 ms or this will run asynchronously). If > 1000ms it the execution task will get into a task queue in the Executor service used. There is no connection with the end of task and the start of next task but a connection with the start of a task and start of a next task.
I have a Quartz trigger that is set to execute a process every minute.
Since concurrent is set to false, if the process takes longer than a minute, future triggers are prevented. However, does this mean that the trigger that attempted to run is now "standing in line" and waiting to be executed?
For example, if the process takes 10 minutes to execute, will there be 10 triggers sitting there waiting to execute. I am attempting to prevent a buildup on the server.
No. If concurrency is set to false (with anottation #DisallowConcurrentExecution) further jobs won't start if actual is still running.
See Job State and Concurrency in docu.
The accepted answer is not correct.
I just did the test with quartz 2.2.3 and the jobs are indeed put on the back burner.
Meaning if the time to process the job is superior to the time between jobs, you will pile up the jobs.
The documentation provided by #1ac0 is not mentioning anything apart the job will not run 'immediately'.
I go to the FTP each 2 mins to upload new files.
I implemented it with java.util.Timer. But after some time - several days or even week - it stops without any exception and without any reason.
I found thread:
Java unlimited thread stops after some time
But there is no particular solution in it.
I read about ScheduledExecutorService, but as far as I understand - it's the same as Timer.
Please give me some ideas!
You can try to set a default Exception handler using Thread.setDefaultUncaughtExceptionHandler() API in your main thread and try to log any throwable/exception that could get swallowed silently.
I just saw that no one have answered this question, maybe because this is a duplicate.
ScheduledExecutorService uses System.nanotime() and Java.util.Timer uses System.currentTimeMillis().
System.currentTimeMillis() depends up on system time and System.nanotime() gives nanoseconds since some fixed arbitrary initial time and is not related to system time. So any change in system time (due to NTP time correction or system stand-by) may or may not impact Timer execution. This would be the reason that your timer fails.
For more details please refer - What should Timertask.scheduleAtFixedRate do if the clock changes?
I'm using a ScheduledExecutorService to provide an update to a database every hour with the scheduleAtFixedRate method. The problem is that it gradually gets later - in long service I've been logging it and it's about a second a day.
I made a small class just to examine this aspect - seems to work fine when nothing is happening on the PC ( running WinXP ) but if things are going on it rapidly gets later. 18:00:00.5 last night was its first log and this morning was 09:00:00.5 then 10:00:05.9, 11:00:26.8, 12:00:45.3, 13:01:07.8...
I can attach the code although my example isn't the smallest.
Anyone else experienced this? Any ideas why this isn't working properly?
I can think of lots of ways around it but I'd really like to know why it doesn't work as advertised!
Thanks, Mike
This is normal AFAIK. With scheduleAtFixedRate, If any execution of this task takes longer than its period, then subsequent executions may start late. That being said, I'd recommend scheduleWithFixedDelay. This will ensure that tasks are carried out at the specified delay interval.
How does quartz track the time ? Is it a continuous timer running in background or does it somehow uses the OS scheduler or is it something else ?
Which class actually holds this feature ?
Thanks.
As far as I digged into Quartz source code, I found (at least for StdScheduler implementation which is proxy of QuartzScheduler) that its scheduling thread QuartzSchedulingThread uses System.currentTimeMillis() for prediction of the next job trigger run.
Please look inside QuartzSchedulerThread.java .