[jira] [Comment Edited] (CURATOR-622) Add Randomness to LeaderLatch Elections

["Jordan Zimmerman (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CURATOR-622?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17443262#comment-17443262 ] 

Jordan Zimmerman edited comment on CURATOR-622 at 11/14/21, 8:52 AM:
---------------------------------------------------------------------

> There is no reason to believe that the instances contending for a latch are random in many operational environments

Why not? If n instances contend for a ZNode at around the ame time sequence number they receive is non-deterministic.

> In the current implementation, the LeaderLatch is operating more as a leadership queue than an election system

The current implementation is _fair_. Fairness in locks requires a queue (fair locks in the JDK do this).

> By adding a random factor into the internal election process...

This will be very hard to do without completely re-writing the LeaderLatch recipe. The current implementation takes advantage of the sequence numbers when instances who don't have the lock watch their predecessor - see line 578, the watch patch is the ZNode path of the previous node.

I'm very much - 1 on this change for LeaderLatch. Instead a new recipe should be written to handle your use case.


was (Author: randgalt):
> There is no reason to believe that the instances contending for a latch are random in many operational environments

Why not? If n instances contend for a ZNode at around the sequence number they receive is non-deterministic.

> In the current implementation, the LeaderLatch is operating more as a leadership queue than an election system

The current implementation is _fair_. Fairness in locks requires a queue (fair locks in the JDK do this).

> By adding a random factor into the internal election process...

This will be very hard to do without completely re-writing the LeaderLatch recipe. The current implementation takes advantage of the sequence numbers when instances who don't have the lock watch their predecessor - see line 578, the watch patch is the ZNode path of the previous node.

I'm very much - 1 on this change for LeaderLatch. Instead a new recipe should be written to handle your use case.

> 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)