Limitations
Explanation
A cluster that distributes its events is still not one XWiki: several features behave as if their node were alone, and three of those consequences are worth knowing before a cluster carries real traffic.
The load balancer has to be sticky
A session belongs to the node that created it and is not shared with the others, so a visitor whose requests are spread over the nodes loses their session, and with it their login and anything they were in the middle of editing. Add a Load Balancer is where stickiness is configured; it is a requirement of running XWiki in a cluster, not a tuning choice.
Every node runs every scheduled job
The Scheduler is not cluster-aware. XWiki ships no Quartz configuration of its own, so Quartz falls back to its in-memory job store, which is private to each JVM: each node holds the whole schedule and runs all of it. A job that only computes something is merely done several times; a job with a side effect happens once per node, which is how administrators usually meet this, as mail delivered as many times as there are nodes, reported in XWIKI-6235, "In cluster mode, email notifications are sent twice", still open.
The workaround is to let a single node schedule anything, by disabling the scheduler on all the others:
scheduler.enabled = falseThat makes the remaining node a single point of failure for scheduled jobs: while it is down nothing is scheduled at all, and nothing catches up once it is back. The "Clustering" section of the Scheduler Plugin page covers the feature itself.
What a node misses while it is down stays missed
Remote observation sends each event as it happens; there is no journal and no replay. A node that was stopped, or whose channel was stopped, does not learn what it missed when it comes back, it simply starts receiving new events again. The example XWiki itself reports is an extension installed on the other nodes meanwhile, which stays missing from the node that was away: XWIKI-11441, "Stopped cluster members extensions index is out of sync when coming back", also open. So a node that has been away deserves a look at whether it is still in step with the others.
FAQ
The channel has a leader. Does it run the scheduled jobs?
No. A channel does elect a leader, and Verify a Cluster can display it, but nothing in XWiki uses it to decide which node performs a piece of work. Disabling the scheduler everywhere but on one node is the only way to have a job run once.
