You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Stefan Egli (JIRA)" <ji...@apache.org> on 2015/11/12 12:28:11 UTC

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

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

Stefan Egli closed SLING-3253.
------------------------------

> 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.3.4#6332)