Opt-in. The behaviour is enabled by a new scheduler.clusterSingleton property in xwiki.properties, false by default, so that the clusters which disable the scheduler on all the members but one keep working after an upgrade. With true (and remote observation enabled), among the members where scheduler.enabled is true, only the cluster singleton node runs the scheduler. To switch, enable the scheduler on every member, or give the member which runs it a higher observation.remote.singletonPriority. A singleton node whose scheduler is disabled logs a warning, since no member runs the jobs then.
Edits of a job page. A change of the status or of the cron expression of a job is applied by rebuilding the job from its page, as at startup, instead of modifying the scheduled job.
Corrections to the limits.
Planned stop of the singleton node: it stops firing jobs as soon as it starts stopping, before the other members see it leave. The runs falling between that moment and the end of the restore on the new singleton node (up to 30 seconds of wait for the running jobs, the cluster view change and the restore) are skipped. A run still going after the wait can overlap the next run of the same job on the new node.
Crash: the runs are skipped during the failure detection and the restore, and the running one is lost.
A member with a higher priority joining takes the role as soon as it joins the cluster, but starts the scheduler only once its XWiki is initialized. No member runs the jobs in between: up to about a minute for the restart of a background member, much longer without eager initialization. A run started on the previous node is not interrupted and can overlap the first run on the new node.
During a network partition, each side runs every job.
The notification mail job keeps its last fire time in the database: a skipped run is covered by the next one, but two overlapping runs send the same mails.
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
