[jira] [Comment Edited] (SLING-4516) Allow to configure the leader to follow the crx master

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

    [ https://issues.apache.org/jira/browse/SLING-4516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14576706#comment-14576706 ] 

Stefan Egli edited comment on SLING-4516 at 6/8/15 7:49 AM:
------------------------------------------------------------

Important note on applying a config change (in the new {{invertRepositoryDescriptor}} or the {{leaderElectionRepositoryDescriptor}}). In order to understand the implication the config has, the underlying leader election mechanism must be taken into account:
 * discovery.impl computes each instance's {{leaderElectionId}} based on this config (and a few other things like startup time, slingId). This happens at {{activate}} time of the {{DiscoveryServiceImpl}}.
 * upon a new round of cluster voting this {{leaderElectionId}} is then taken into account to both define who is leader and the order of the instances within the cluster. The leader will be the one with the lowest {{leaderElectionId}} and the ordering of instances is a simple sort of the instances based on the same {{leaderElectionId}}
 * a *reconfiguring of discovery.impl does not trigger a cluster voting*. A cluster (view) is stable as long as no instance leaves or joins the cluster.

>From the above mechanism it becomes clear that changing {{invertRepositoryDescriptor}} for example does not have any immediate effect, but that instead a new round of voting must happen.

Voting happens automatically whenever an instance joins or leaves the cluster view (not however on 'just' reconfiguring or a restart where the heartbeats do not '{{heartbeatTimeout}}]).

So, to explicitly force a new voting, use the new JMX method introduced with SLING-4628: "org.apache.sling: DiscoveryServiceImpl (discovery)" MBean with {{startNewVoting}} method - that will thus apply the config change explicitly.


was (Author: egli):
Important note on applying a config change (in the new {{invertRepositoryDescriptor}} or the {{leaderElectionRepositoryDescriptor}}). In order to understand the implication the config has, the underlying leader election mechanism must be taken into account:
 * discovery.impl computes each instance's {{leaderElectionId}} based on this config (and a few other things like startup time, slingId). This happens at {{activate}} time of the {{DiscoveryServiceImpl}}.
 * upon a new round of cluster voting this {{leaderElectionId}} is then taken into account to both define who is leader and the order of the instances within the cluster. The leader will be the one with the lowest {{leaderElectionId}} and the ordering of instances is a simple sort of the instances based on the same {{leaderElectionId}}
 * a reconfiguring of discovery.impl does not trigger a cluster voting. A cluster (view) is stable as long as no instance leaves or joins the cluster.

>From the above mechanism it becomes clear that changing {{invertRepositoryDescriptor}} for example does not have any immediate effect, but that instead a new round of voting must happen.

Voting happens automatically whenever an instance joins or leaves the cluster view (not however on 'just' reconfiguring or a restart where the heartbeats do not '{{heartbeatTimeout}}]).

So, to explicitly force a new voting, use the new JMX method introduced with SLING-4628: "org.apache.sling: DiscoveryServiceImpl (discovery)" MBean with {{startNewVoting}} method - that will thus apply the config change explicitly.

> Allow to configure the leader to follow the crx master
> ------------------------------------------------------
>
>                 Key: SLING-4516
>                 URL: https://issues.apache.org/jira/browse/SLING-4516
>             Project: Sling
>          Issue Type: Improvement
>          Components: Extensions
>    Affects Versions: Discovery Impl 1.0.12
>            Reporter: Timothee Maret
>            Assignee: Stefan Egli
>            Priority: Minor
>             Fix For: Discovery Impl 1.1.2
>
>
> As discussed in [0] in deployments involving a CRX cluster in active/passive setup, it would be beneficial to allow the Sling leader to match the CRX master at all time, thus avoiding to write on the CRX slave.
> This issue is about enabling this as an optional support. This is only relevant for setups on CRX and should not impact other clustering technologies.
> [0] http://apache-sling.73963.n3.nabble.com/Sling-leader-CRX-master-mapping-td4048533.html



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)