By default, scheduling information, such as schedule state and details
of the schedule execution, is stored in RAM. This means that such
information is lost when OpenIDM is rebooted. The schedule configuration
itself (defined in the openidm/conf/schedule-
file) is not lost
when OpenIDM is shut down, and normal scheduling continues when the server is
restarted. However, there are no details of missed schedule executions that
should have occurred during the period the server was unavailable.
schedule-name.json
You can configure schedules to be persistent, which means that the scheduling information is stored in the internal repository rather than in RAM. With persistent schedules, scheduling information is retained when OpenIDM is shut down. Any previously scheduled jobs can be rescheduled automatically when OpenIDM is restarted.
Persistent schedules also enable you to manage scheduling across a cluster (multiple OpenIDM instances). When scheduling is persistent, a particular schedule will be executed only once across the cluster, rather than once on every OpenIDM instance. For example, if your deployment includes a cluster of OpenIDM nodes for high availability, you can use persistent scheduling to start a reconciliation action on only one node in the cluster, instead of starting several competing reconciliation actions on each node.
You can use persistent schedules with the default OrientDB repository, or with the MySQL repository (see Installing a Repository For Production).
To configure persistent schedules, set the "persisted"
property to true in the schedule configuration file
(schedule-.
schedule-name.json)
If OpenIDM is down when a scheduled task was set to occur, one or more
executions 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 OpenIDM should do if scheduled tasks are missed. Possible values are as
follows:
-
fireAndProceed. The first execution of a missed schedule is immediately executed when the server is back online. Subsequent executions 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.

