[
https://issues.apache.org/jira/browse/CURATOR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443459#comment-17443459
]
Cam McKenzie commented on CURATOR-622:
--------------------------------------
[~randgalt] , agreed that the existing recipe's functionality should not
change. This randomness is definitely an optional extra.
Getting the previous node watching logic is definitely going to be the most
complicated piece of code. Each client would need to watch on the children of
the latch path and reevaluate its Watch's (cancel old and create new) if its
'previous' node has changed.
> 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)
