[
https://issues.apache.org/jira/browse/SLING-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124848#comment-15124848
]
Timothee Maret edited comment on SLING-5435 at 1/30/16 11:20 AM:
-----------------------------------------------------------------
bq. Ok, it seems we agree that you're example works similar whether the leader
election waits for the repo sync or not
Not exactly equivalent. With the current implementation the "SomeImporter" must
wait on the repo-sync before importing even though it does not need to.
bq. do we have an example where the code is acting on a change in leader
election and needs a repo sync?
I think this category contains the TopologyEventListener in Sling, which AFAIU
do need to wait until the new leader sees the previous leader changes before
proceeding (that is to avoid missing execution or double execution as much as
possible).
The existing topology event support fits those use case.
The other category (acting on a change in leader election *and does not* need a
repo sync) contains the use cases I shared as well as the example code above.
The existing topology event support impose to wait on the repository sync where
there is no need for it.
was (Author: marett):
bq. Ok, it seems we agree that you're example works similar whether the leader
election waits for the repo sync or not
Not exactly equivalent. With the current implementation the "SomeImporter" must
wait on the repo-sync before importing even though it does not need to.
bq. do we have an example where the code is acting on a change in leader
election and needs a repo sync?
I think this category contains the TopologyEventListener in Sling, which AFAIU
do need to wait on the previous leader change before proceeding.
The existing topology event support fits those use case.
The other category (acting on a change in leader election *and does not* need a
repo sync) contains the use cases I shared as well as the example code above.
The existing topology event support impose to wait on the repository sync where
there is no need for it.
> Decouple processes that depend on cluster leader elections from the cluster
> leader elections.
> ---------------------------------------------------------------------------------------------
>
> Key: SLING-5435
> URL: https://issues.apache.org/jira/browse/SLING-5435
> Project: Sling
> Issue Type: Improvement
> Components: General
> Reporter: Ian Boston
>
> Currently there are many processes in Sling that must complete before a Sling
> Discovery cluster leader election is declared complete. These processes
> include things like transferring all Jobs from the old leader to the new
> leader and waiting for the data to appear visible on the new leader. This
> introduces an additional overhead to the leader election process which
> introduces a higher than desirable timeout for elections and heartbeat. This
> higher than desirable timeout precludes the use of more efficient election
> and distributed consensus algorithms as implemented in Etcd, Zookeeper or
> implementations of RAFT.
> If the election could be declared complete leaving individual components to
> manage their own post election operations (ie decoupling those processes from
> the election), then faster election or alternative Discovery implementations
> such as the one implemented on etcd could be used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
