[
https://issues.apache.org/jira/browse/SLING-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15123629#comment-15123629
]
Timothee Maret edited comment on SLING-5435 at 1/29/16 3:58 PM:
----------------------------------------------------------------
bq. The leader is already elected in 2. I guess you assume there is a delay
between the leader election and sending the event, which then happens in 5.
Exactly, I don't assume it, it does exist.
bq. But there is always some delay between 2 and 5
+1
with the current implementation, the delay is somewhat related to the load and
may be counted in hour(s).
What I propose is to reduce that delay to a more constant time which may be a
couple of CPU cycles.
bq. So the above situation can happen in both cases
True, in one case much more likely than in the other
bq. Once the changed event is sent, you might want to start the import
Yes, that's the proper solution to not lose the import.
But even if you won't lose the import invocation, why did you wait on the
repository ?
was (Author: marett):
bq. The leader is already elected in 2. I guess you assume there is a delay
between the leader election and sending the event, which then happens in 5.
Exactly, I don't assume it, it does exists.
bq. But there is always some delay between 2 and 5
+1
with the current implementation, the delay is somewhat related to the load and
may be counted in hour(s).
What I propose is to reduce that delay to a more constant time which may be a
couple of CPU cycles.
bq. So the above situation can happen in both cases
True, in one case much more likely than in the other
bq. Once the changed event is sent, you might want to start the import
Yes, that's the proper solution to not lose the import.
But even if you won't lose the import invocation, why did you wait on the
repository ?
> 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)
