You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@curator.apache.org by "Jordan Zimmerman (Jira)" <ji...@apache.org> on 2021/11/13 23:19:00 UTC
[jira] [Commented] (CURATOR-622) Add Randomness to LeaderLatch Elections
[ https://issues.apache.org/jira/browse/CURATOR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443217#comment-17443217 ]
Jordan Zimmerman commented on CURATOR-622:
------------------------------------------
It would help if you explained why this is better. The instances contending for a latch (or any lock) are random already. How is this better?
> Add Randomness to LeaderLatch Elections
> ---------------------------------------
>
> Key: CURATOR-622
> URL: https://issues.apache.org/jira/browse/CURATOR-622
> Project: Apache Curator
> Issue Type: Improvement
> Components: Recipes
> Reporter: Tim Black
> Priority: Major
>
> Currently, LeaderLatch uses EPHEMERAL_SEQUENTIAL nodes, with the next leader chosen by the lowest numbered node. In a multi-server environment where each server is a participant in multiple elections, the result is that the leader will always be the server that has been up the longest.(Or first to be restarted during a rolling restart)
> Instead of using sequentially numbered nodes, I propose instead that the node number for a new participant be created by adding a random number(From a constrained range) to the current leader number.(Defaults to zero) If a node with that number exists, repeat until an available node is found. After initial node creation, all other aspects of the leader election will remain unchanged.
> I have an implementation for this that I am testing locally and will submit a PR once the tests are complete.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)