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.

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.

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.

Note

As 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.

Example

Let 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.
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).

Example

As 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.

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.

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.

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.