[jira] [Resolved] (SLING-3253) leader not stable due to: leader recalculated instead of using pre-calculated leader based on leaderElectionId

["Stefan Egli (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SLING-3253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stefan Egli resolved SLING-3253.
--------------------------------

    Resolution: Fixed

Fixed. leaderId is now properly taken from the pre-calculated /var/discovery/impl/establishedView/%cluster-view-id%/leaderId.

As a result:
 * in discovery.impl 1.0.0: the leader is always the instance with the lowest slingId
 ** this means that the leader can change if a new instance with a lower slingId joins or leaves.
 * in discovery.impl 1.0.2: there are two situations:
 ** with leaderElectionRepositoryDescriptor empty: the first started instance becomes and remains leader until it is stopped
 ** with leaderElectionRepositoryDescriptor configured: the first started instance where that descriptor-value is 'false' becomes and remains leader until it is stopped. An instance with descriptor-value 'true' can only become and stay leader if/as long as there are no instances with descriptor-value 'false'.

PS: 'start/stop' of an instance above is determined by discovery.impl bundle activate/deactivate.
PPS: an example of the leaderElectionRepositoryDescriptor is for it to be set to crx.cluster.master, in which case it forces the leader to be the first slave. This prevents an edge case problem with job distribution on the master.

> leader not stable due to: leader recalculated instead of using pre-calculated leader based on leaderElectionId
> --------------------------------------------------------------------------------------------------------------
>
>                 Key: SLING-3253
>                 URL: https://issues.apache.org/jira/browse/SLING-3253
>             Project: Sling
>          Issue Type: Bug
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.0.0
>            Reporter: Stefan Egli
>            Assignee: Stefan Egli
>            Priority: Critical
>             Fix For: Discovery Impl 1.0.2
>
>
> Discovery.impl stores a 'leaderElectionId' property as part of the instance node in the repository. The idea of this property is to control the leader election: the instance with the lowest leaderElectionId in an established cluster-view becomes leader.
> This leaderElectionId is created properly (composed of the leaderElectionRepositoryDescriptor, the bundle-activation time and the slingId), it is propagated to the winning established cluster view and all - but is never really taken into consideration for the leader election.
> Instead, in discovery.impl 1.0.0 the leader election is only based on the slingId. Which makes it robust, yes, but not stable - since a joining slave can have a lower slingId than the current leader.



--
This message was sent by Atlassian JIRA
(v6.1#6144)