[ https://issues.apache.org/jira/browse/SLING-5435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15126162#comment-15126162 ]
Carsten Ziegeler commented on SLING-5435: ----------------------------------------- [~egli] ok yes, maybe marking the listener with a property is better than introducing a new event type. For the API, for now we could simply state that the API only handles one case (sync'ed). Adding a new method looks too confusing to me , given the little benefit. I don't really expect client code to be based on the API - it's more an informative API > 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)