Skip to content

Leader Ready

LEADER_READY - wait for followers to reach the leader's append position, then closes the Election

On Entry

Enters from LEADER_INIT. The leader has processed up to the end of the Log Recording, it has created the Log Publication, which is being recorded by the Archive, and its Clustered Service has a Subscription to it. It just needs to wait for enough followers to catch up to its logPosition.

Description

This state starts by getting the Consensus Module to update the leader position, which is what the leader Consensus Module normally does anyway, outside an Election. This:

  • updates its ClusterMember's logPosition to the appendPosition (this won't be changing in LEADER_READY, but it also updates the 'last updated' timestamp on it, to show that it is current) - this is used to calculate the quorumPosition
  • sets the commitPosition to the quorumPosition and publishes a CommitPosition message if it has changed, or hasn't been sent for 200ms
  • sets its commit-pos counter to commitPosition
  • sweeps uncommitted entries up to the commitPosition - this just clears some temporary state in the Consensus Module

It publishes a NewLeadershipTerm on an interval of 200 ms.

While in this state, it will be receiving AppendPosition messages from the followers and updating their ClusterMember state. It is waiting for the member(s) that voted for it to have caught up (reach its logPosition), or after a timeout of 10 seconds, for a quorum of members to have caught up. Their positions were reset in LEADER_REPLAY, so the leader will need to receive at least one AppendPosition message.

Once enough have caught up, it appends a NewLeadershipTermEvent to the Log (not to be confused with the NewLeadershipTerm consensus message). This message is recorded in the Log that so that leadership term state will be recreated at the correct position when the Log is replayed.

It then notifies the ConsensusModuleAgent that the election is complete, which does the following:

  • it prepares client sessions for the new leadership term
    • if the leader is starting, the clients might be long gone, so it marks each client session as closing with a TIMEOUT reason, and doesn't reconnect them
    • otherwise, if the leader is not starting, that means there has just been an Election and the leader may have just changed. Any client sessions that were marked as OPEN before the Election are reconnected. After reconnecting them, a flag is set on each of them that a NewLeaderEvent is pending. This will be sent later, in the ConsensusModuleAgent's duty cycle here. When clients receive it, they will reconnect to the new leader
  • activates the Cluster Control Toggle by setting it to NEUTRAL, so it can be used to request new actions (it was deactivated in INIT)
  • a new RecoveryPlan is created
  • it connects the Ingress - the doors are open for business!
  • the ConsensusModuleAgent sets its election field to null, throwing away the Election object

It then moves to CLOSED.

On Exit

The leader and enough followers for consensus have caught up to the end of the existing Log and are ready to start processing new messages. The Ingress is open and clients can connect. If the Election was not caused by the cluster starting, any Egress connections will be reconnected. Any existing clients will have been notified of the new leader and will connect to it. The Election moves to the CLOSED state and is discarded by the Consensus Module.