Spring Quartz Execute Time - spring

Question

I have set an spring quertz timer with following expressions:
#Scheduled(cron = "${quartz.expire.data.cron:0 0 0 * * ?}")
But it starts a little bit ahead as shown in our logs:
2017-10-22 23:59:59.899 scheduler-4
Why?

Answer 1

This might come from the calculation for the next execution time.
In the schedule method of the ReschedulingRunnable, the time is taken from the nextExecutionTime at line 68. The actual delay until execution gets calculated at line 72.
66 public ScheduledFuture<?> schedule() {
67 synchronized (this.triggerContextMonitor) {
68 this.scheduledExecutionTime = this.trigger.nextExecutionTime(this.triggerContext);
69 if (this.scheduledExecutionTime == null) {
70 return null;
71 }
72 long initialDelay = this.scheduledExecutionTime.getTime() - System.currentTimeMillis();
73 this.currentFuture = this.executor.schedule(this, initialDelay, TimeUnit.MILLISECONDS);
74 return this;
75 }
76 }
Now let's see what happens in the nextExecutionTime method of the CronTrigger:
72 #Override
73 public Date nextExecutionTime(TriggerContext triggerContext) {
74 Date date = triggerContext.lastCompletionTime();
75 if (date != null) {
76 Date scheduled = triggerContext.lastScheduledExecutionTime();
77 if (scheduled != null && date.before(scheduled)) {
78 // Previous task apparently executed too early...
79 // Let's simply use the last calculated execution time then,
80 // in order to prevent accidental re-fires in the same second.
81 date = scheduled;
82 }
83 }
84 else {
85 date = new Date();
86 }
87 return this.sequenceGenerator.next(date);
88 }
At Line 86, the time is taken. The taken moment is the base to calculate the next execution time for the cron definition which happens in sequenceGenerator.next
134 Calendar calendar = new GregorianCalendar();
135 calendar.setTimeZone(this.timeZone);
136 calendar.setTime(date);
137
138 // First, just reset the milliseconds and try to calculate from there...
139 calendar.set(Calendar.MILLISECOND, 0);
140 long originalTimestamp = calendar.getTimeInMillis();
141 doNext(calendar, calendar.get(Calendar.YEAR));
142
143 if (calendar.getTimeInMillis() == originalTimestamp) {
144 // We arrived at the original timestamp - round up to the next whole second and try again...
145 calendar.add(Calendar.SECOND, 1);
146 doNext(calendar, calendar.get(Calendar.YEAR));
147 }
148
149 return calendar.getTime();
This certainly takes a few milliseconds, which will be missing within the initialDelay.
Proof
A small test to proof this looks like following. I create a regular CronTrigger, and a manipulated CronTrigger
#Test
public void test() {
CronTrigger normalTrigger= new CronTrigger("0 0 0 * * ?");
Date d2 = normalTrigger.nextExecutionTime(new SimpleTriggerContext());
long initialDelay2 = d2.getTime() - System.currentTimeMillis();
System.out.println("Normal trigger:"+ initialDelay2);
//create a manipulated trigger, which takes longer to return the nextExecutionTime
CronTrigger manipulated = new CronTrigger("0 0 0 * * ?") {
#Override
public Date nextExecutionTime(TriggerContext triggerContext) {
Date nextExecutionTime = super.nextExecutionTime(triggerContext);
try {
Thread.sleep(5000);
} catch (InterruptedException ex) {
//ignore
}
return nextExecutionTime;
}
};
Date d = manipulated.nextExecutionTime(new SimpleTriggerContext());
long initialDelay = d.getTime() - System.currentTimeMillis();
System.out.println("Manipulated trigger:" +initialDelay);
}
From the result, you see that the manipulated trigger will trigger 5 seconds earlier than the non-manipulated, because it took 5 seconds longer to return the nextExecutionTime.