[
https://issues.apache.org/jira/browse/CURATOR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443452#comment-17443452
]
Cam McKenzie commented on CURATOR-622:
--------------------------------------
hey [~randgalt] , I thought that [~FreemanB] 's suggestions were reasonable. I
can easily see the example above occurring in a long running production system.
I suggested that he look at modifying the existing LeaderLatch as to me it
seemed to fit in there with minimum changes.
On further investigation into the way that a client only watches the previous
zNode in the list of sorted children, you're probably right that it's going to
be much more complex. My superficial thinking was that ordering of the random
nodes would be handled by sorting as it is currently, but with the use of
random numbers instead of sequential ones, it means that the 'previous' node in
the sorted list of children potentially changes each time a new entry is added
to the list. So, using the current algorithm would work (I believe, without
putting too much thought into it), but would be less efficient as clients are
going to check for leadership when they won't obtain it.
> 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)
