Server Downtime, Daylight saving time, and Time Shift 
Use
This section outlines the Java Scheduler’s behavior in irregular circumstances. In particular these are server downtime, daylight saving time, time shift or system overload, and execution overlap.
Note
The Java Scheduler is not a real-time system. There is no guarantee that jobs are started exactly to the second. However, when the system is not overloaded too heavily, jobs will be started in a timely manner. This means that the majority of jobs will be running within a few milliseconds after the specified start time.
Server Downtime
Description
The Java Scheduler is a service of AS Java. Downtime denotes the period when AS Java (or only the scheduler service) is not running. During such a period no job can be triggered by the scheduler.
Note
There is a difference between AS Java downtime and Java Scheduler unavailability during garbage collection or general system overload. Java Scheduler unavailability will be handled in the subsection Time Shift. The main difference is that during downtime, nonpersistent (for example transient) data will be lost, while Java Scheduler unavailability appears like a jump in system time to the scheduler.
Rules
When AS Java is back online after a downtime, the following has to be considered:
Tasks With More Than One Expiration Time
Rule: All expiration times that lie in the AS Java downtime period are skipped and will not run later.
For example we have a task that schedules a job every hour and AS Java is down from 12:30 until 14:30.
Further Behavior:
If you turn back the system time before restarting AS Java, jobs that already have run (or were skipped) will run again. This is because the transient data which jobs already have run is lost during downtime. This only applies to tasks that are in state active.
A task is set on hold when four of its jobs failed in a row. More information: Job Scheduling Through the Scheduler API
After restarting AS Java, a task's state will be the same as before the downtime. However, Java Scheduler will “forget” about jobs that failed before the downtime. If a task scheduled up to three jobs that failed in a row before the downtime, it will start counting those failed jobs from zero after restarting the Java Scheduler service. This is because the “failed jobs counter” is transient data which is lost during downtime.
As described in the Execution Overlap subsection, jobs of one single task run one after the other. When there is a job waiting for the termination of the previous job of the same task, Java Scheduler “forgets” about the waiting job during downtime. This is because the fact that there is a waiting job is transient data which is lost during downtime.
Tasks With Only One Expiration Time
If the expiration time lies in the downtime period, the job will be started when Java Scheduler is back online, independently of how long it is overdue.
This behavior is the same as after a time shift forward.
Daylight Saving Time (DST) and Time Changeover
Time changeover denotes the transition of standard time (ST) to daylight saving time (DST) and vice versa. Time changeover is not a jump in system time. It is only a change of the representation of system time to the human reader with respect to the specified time zone. Different time zones may have differing rules when DST starts and ends. This change has an important impact for Cron entries which must be considered, as Cron entries rely on patterns of time representation. The behavior of the Recurring entries is a bit complicated at first sight.
In this section we assume that at the transition of standard time (ST) to daylight saving time (DST), the time representation jumps from 1:59:59 (ST) to 3:00:00 (DST). The transition back is a jump from 2:59:59 (DST) to 2:00:00 (ST).
In order to describe the Java Scheduler’s behavior at time changeover, we describe here how Java Scheduler calculates expiration times of a task from Cron and Recurring entries at the day of time changeover.
Recurring Entries
The behavior for recurring entries always follows one simple rule: A job will be scheduled every period length of real time that passes by.
This rule has the following implications:
A recurring entry that schedules a job every 24 hours and has its first expiration at 13:00 (ST) during standard time, will run at 14:00 (DST) during daylight saving time. That is, because from 13:00 at the day before time changeover to 14:00 at the day of time changeover, 24 hours pass by.
A recurring entry that schedules a job every 24 hours with first expiration at 2:30 (ST) at a given day during standard time will schedule the job at 3:30 (DST) during daylight saving time. At the day of transition from DST to ST it runs at 2:30 (ST) standard time.
Another example is a recurring job that runs every half an hour. At the transition from ST to DST it runs at …, 01:30 (ST), 03:00 (DST), 03:30 (DST)….
At the transition from DST to ST it runs at …, 1:30 (DST), 2:00 (DST), 2:30 (DST), 2:00 (ST), 2:30 (ST) and so on.
Cron Entries
Time changeover from ST to DST
At the day of time changeover from ST to DST, the clock will not show any time from 02:00 to 2:59. For Cron entries that means that potential expiration times in this interval will not cause a job to be scheduled as the start conditions are not met.
NoteAs a consequence, a daily Cron Job at 02:00 will not be scheduled at the day of time changeover from ST to DST. It is lost at this day and will not run later.
End of the note.
ExampleLet us have a cron task that runs every 30 minutes. Technically this is a task with the CronEntry *:*:*:*:*:*/30. At the day of Time changeover from ST to DST it runs at …, 01:30 (ST), 03:00 (DST), 03:30 (DST)…. These are the same execution times as in the example of the recurring task above.
End of the example.Time changeover from DST to ST
At the day of time changeover from DST to ST, the clock will show the times from 02:00 to 2:59 twice. The first time it is DST, the second time it is ST. However, no Cron job will be scheduled from 02:00 (DST) to 2:59 (DST) at this day. The expiration times in the interval from 02:00 to 2:59 will only take place from 02:00 (ST) to 2:59 (ST).
ExampleAs above, we use the cron task that runs every 30 minutes (the task with the CronEntry *:*:*:*:*:*/30). At the day of time changeover from DST to ST it runs at …, 1:00 (DST), 1:30 (DST), 2:00 (ST), 2:30 (ST), …. The possible execution times at 2:00 (DST) and 2:30 (DST) are skipped. Note that this is different from the behavior or the corresponding recurring task above.
End of the example.Further consequences:
A daily Cron Job at 02:30 will be scheduled at 02:30 (ST) at the day of time changeover from DST to ST.
An hourly Cron job that is scheduled to run at half past the hour will only be scheduled at …, 00:30 (DST), 01:30 (DST), 02:30 (ST), 03:30 (ST), … at the day of time changeover from DST to ST. It is not scheduled at 02.30 (DST).
The reason for this behavior is that the implementation for Cron entries relies on the java.util.Calendar class of the Sun JavaTM 2 Platform. It interprets the times from 02:00 to 2:59 as standard time.
Time Shift, Jumps in System Time and Java Scheduler Service Unavailability
Java Scheduler regularly reads the system time of the machine. A “jump in time” or a “time shift” denotes the situation when the read time is not as expected. Due to certain circumstances the system time may jump to some point in time in the past or future. This chapter explains the consequences for job scheduling.
Note
Time changeover to daylight saving time and back is not a time shift. For behavior at daylight saving time see the Daylight Saving Time subsection.
Time Shift Forward
When Java Scheduler reads the system time and it has advanced more than expected, we talk about a time shift forward or a jump in time forward. This may occur when:
the system time is manually forwarded
the machine wakes up from suspend mode (hibernation). This normally happens only on laptops.
the Java Scheduler service was unavailable due to garbage collection, communication failure, or general system overload.
Tasks with More Than One Execution Time
When Java Scheduler recognizes a jump in time forward, jobs that should have run in the meantime are usually skipped. A detailed description is given in the list below. The motivation for this behavior is to prevent (further) system overload after a jump in system time. When system overload occurs and there are important jobs, an administrator should check the system to ensure that all the necessary jobs have run successfully.
In detail, when the scheduler recognizes a jump in time forward, the following rules apply:
Rule 1: If the next planed execution time for a job of some task is at least two minutes overdue, all the jobs that should have run in the meantime are skipped. This is the same behavior as after AS Java downtime.
Rule 2: If the next planed execution time for a job of some task is up to two minutes overdue, the corresponding job will be started immediately.
Rule 3: If the next planed execution time for a job of some task is still in the future, no expiration time is affected. It will be started as usual when the planed expiration time is reached.
Example
We have a task that schedules a job every hour (e.g. a task with the CronEntry *:*:*:*:*:0).
Example for Rule 1
If you put forward the system time from 2:59 to 5:01, the expiration times at 3:00, 4:00, and 5:00 are skipped. The next expiration time will be at 6:00. Note that the expiration time at 5:00 is skipped, because the next planed expiration time before the jump in time was 3:00, and that is more than two minutes overdue after the jump in time.
Example for Rule 2
If you put forward the system time from 2:59 to 3:01, the job that should have run at 3:00 will be started immediately when the scheduler recognizes the jump in time. This will happen within the next 20 seconds.
Note that if you put the system time from 2:59 to 3:01:50 it is not guaranteed that the scheduler recognizes the jump in time before 3:02:00. In this case rule 1 would apply and the expiration time at 3:00 would be skipped.
Example for Rule 3
If you put forward the system time from 2:30 to 2:59, the next expiration time remains unchanged at 3:00.
Tasks with Only One Execution Time
There is an exception to the above behavior. Jobs with only one single execution time will not be skipped. When it is recognized that their scheduled execution time is overdue, they will be started immediately. This also applies to the case when the system was down at the scheduled execution time. More information is available in the Server Downtime subsection.
Time Shift Back
A time shift back only occurs when you turn back the system time manually. This should not be necessary in a productive system. When you turn back the system time, jobs that already have run or have been skipped will not run (again). However, if you restart the server (or only the Java Scheduler service) after turning back the system time, these jobs will be started again as described in the subsection Server Downtime. This is because the progress of a task is transient data.
Note
When you turn time forward for testing purpose or whatever, jobs that should have run in the meantime will be skipped in accordance to the rules for time shift forward. When you turn back time after these jobs have been skipped, they will not run at all if you do not restart AS Java.
Execution Overlap
Jobs of different tasks run independently of each other. That also means that two or more instances of the same or different job definitions can be running at the same time if they are scheduled by different tasks.
In contrast to that, jobs of one single task run one after the other. That means that when a job is still running at the time the next job is scheduled, the next job will be delayed until the termination of the previous one. This “waiting for the previous job to terminate” is not accumulative. This means that there will be at most one job waiting to run. If a task schedules a job instance when there is currently running one instance and one waiting, then the newly scheduled instance will be skipped. This behavior applies to all tasks. There is no difference between tasks with only a single Cron or Recurring entry or with both. The motivation of this behavior is to avoid large queues of jobs.
Example
Let us have a task that schedules a job every 30 minutes with first execution time at 2:00 and the jobs take 50 minutes to terminate. The next execution times will be at 2:50, 3:40 and so on, as shown in the picture below. The job with scheduled time 3:30 will be skipped, because the job of 3:00 is still waiting.
