-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The election process may elect a leader who has left the group #259
Comments
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. |
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. |
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 |
How about letting the election thread handle view change events serially |
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 The other two scenarios you mentioned happen because the 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. |
Created test cases for the scenarios mentioned in the GitHub issue and the fixes. Elected leader leaving before the voting thread has finished. This causes a liveness issue on both ELECTION and ELECTION2. We can fix this by stopping the voting thread before starting it again. Scenarios the coordinator leaves before finishing the election process and a majority still exists. ELECTION algorithm has a liveness issue in this case, since it does not take into account changes in the view coordinator. We handle this case by calculating if the coordinator has changed between views, there is a majority, it is currently the coordinator, and there is no leader elected. Close jgroups-extras#259.
Created test cases for the scenarios mentioned in the GitHub issue and the fixes. Elected leader leaving before the voting thread has finished. This causes a liveness issue on both ELECTION and ELECTION2. We can fix this by stopping the voting thread before starting it again. Scenarios the coordinator leaves before finishing the election process and a majority still exists. ELECTION algorithm has a liveness issue in this case, since it does not take into account changes in the view coordinator. We handle this case by calculating if the coordinator has changed between views, there is a majority, it is currently the coordinator, and there is no leader elected. Close #259.
I'll release a new version this week. |
1.0.13.Final is available in central for use. |
The election process is only happened on coordinator and in a separate thread. Assume there a cluster with 3 nodes A, B and C. A is the coordinator, and C has longer log, so C being elected to the leader, before the election result being published out, C leave the group and the view has been updated in another thread, then the election result is applied to all nodes.
Check my comment in the source code.
The text was updated successfully, but these errors were encountered: