[ https://issues.apache.org/jira/browse/SLING-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124895#comment-15124895 ]
Carsten Ziegeler commented on SLING-5435: ----------------------------------------- Ok, sorry for my slow working brain, I think I understand the problem now as well :) It might happen that the old leader did a change, which the new leader doesn't see yet and therefore the new leader might try a similar operation. Which then either results in conflicts or duplicate processing etc. Adding a new event type like LEADER_CHANGED sounds like a good solution to me > 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)