Persistent schedules
By default, scheduling information is persistent. The schedule state is stored in the repository rather than in memory. This ensures that schedules survive server restarts and effectively manages execution across a cluster. In a persistent model, a scheduled task launches on only one node in the cluster.
| Non-persisted (in memory) schedules are deprecated and will be removed in a future release of IDM. |
|
Persistent schedules rely on timestamps. In a deployment where IDM instances run on separate machines, you must synchronize the system clocks of these machines using a time synchronization service that runs regularly. The clocks of all machines involved in persistent scheduling must be within one second of each other. For information on how you can achieve this using the Network Time Protocol (NTP) daemon, refer to the NTP RFC. |
To configure persistent schedules, set persisted to true in the schedule configuration.
If the server is down when a scheduled task was set to occur, one or more runs of that schedule might be missed. To specify what action should be taken if schedules are missed, set the misfirePolicy in the schedule configuration file. The misfirePolicy determines what IDM should do if scheduled tasks are missed. Possible values are as follows:
fireAndProceed-
The first run of a missed schedule is immediately implemented when the server is back online. Subsequent runs are discarded. After this, the normal schedule is resumed.
doNothing-
All missed schedules are discarded and the normal schedule is resumed when the server is back online.