[
https://issues.apache.org/jira/browse/SLING-3750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carsten Ziegeler updated SLING-3750:
------------------------------------
Fix Version/s: (was: Discovery Impl 1.0.12)
Discovery Impl 1.0.14
> Delay discovery-service readiness until first vote has finished, to avoid
> leader being overthrown
> -------------------------------------------------------------------------------------------------
>
> Key: SLING-3750
> URL: https://issues.apache.org/jira/browse/SLING-3750
> Project: Sling
> Issue Type: Bug
> Components: Extensions
> Affects Versions: Discovery Impl 1.0.8
> Reporter: Stefan Egli
> Assignee: Stefan Egli
> Priority: Critical
> Fix For: Discovery Impl 1.0.14
>
>
> The current implementation of discovery.impl has a subtle problem at startup.
> Consider the following problem happening with two simultaneous starts:
> * two (sling) instances start at roughly the same time
> * the goal is to write a service which runs on one of the two only, ever
> * to achieve that, on a TopologyEventListener is used to get hold of the
> latest TopologyView and derive whether the local instance is leader or not
> * currently, upon registration of a TopologyEventListener, a TOPOLOGY_INIT
> event is sent out immediately with the current TopologyView available
> * right after startup though - hence before the first voting has passed -
> discovery.impl considers itself to be in so-called "isolated" mode, creates a
> topology which contains only itself, and makes itself leader (since every
> cluster must have a leader)
> * that means, both instances will receive that isolated view in the
> TOPOLOGY_INIT and are marked as leader (which is kind of right as they don't
> know about any other instance yet - but also wrong as it is not yet an
> established view)
> * at the same time, they both start voting, then find out about each other
> and establish a view where one of the two is marked as leader - hence for the
> other of the two a 'coup d'etat' is happening (the leader is overthrown even
> though the instance did not crash).
> This is certainly very problematic and should be avoided.
> The suggested way to avoid this is to delay both the time when the
> discovery.impl service is registered with OSGi (by making it a @Component
> only and registering it as a service explicitly after the first voting) - and
> by delaying the sending of TOPOLOGY_INIT until again said first voting is
> finished.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
