The election process may elect a leader who has left the group about jgroups-raft HOT 7 CLOSED

Thanks for reporting, @yfei-z. I added some more coverage to view changes during the election, but this scenario might still be an issue. I'll run a few tests to confirm it and open a PR with a fix if necessary.

from jgroups-raft.

There is another situation, if the coordinator itself leave the group before it send the elected message out, then the cluster will have no leader for this term, and the new coordinator won't start the election process for next term.

from jgroups-raft.

I think view change during election process will cause a lot of problems. Another one is if 2/3 of nodes are electing, before coordinator set itself to be the leader, view has changed to 1/3, only coordinator is online, then the cluster is working without majority nodes. Although stopVotingThread will wait at most 100ms before set the leader to null under lost case, but I think it still possible.

from jgroups-raft.

How about letting the election thread handle view change events serially

from jgroups-raft.

I created some tests for all the examples you mentioned, and they all resulted in a liveness problem, no safety issues, even the one split in (1/3 and 2/3). I believe we don't need to go all in on handling the changes serially. I'll give some more context and possible solutions.

For the first, we can synchronize the voting thread stop/start. The start/stop uses the intrinsic lock. Maybe we'll need to add a synchronized block before sending the message and stopping to check the thread interrupt state. Another option is if the view result is leader_lost, we can stop and start the voting thread.

The other two scenarios you mentioned happen because the ELECTION does not consider who was the past coordinator. This issue causes the network partition or the coordinator leaving cases to result in a no_change. In the network partition, you don't end with two working partitions. Instead, it would end with two leaderless partitions that don't take commands, even though one has a majority. On the other hand, ELECTION2 also calculates the previous coordinator. However, it has an additional pre-voting phase before the election.

I have the tests in place, so I'll see something simpler to solve it. And, also take the chance and see if I think of some problems.

from jgroups-raft.

I'll release a new version this week.

from jgroups-raft.