Make virtual group assignment for FaultZoneBasedVirtualGroupAssignmentAlgorithm deterministic #3056
+93
−66
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Issues
FaultZoneBasedVirtualGroupAssignmentAlgorithmis non-deterministic #3057Description
(Write a concise description including what, why, how)
When using
FaultZoneBasedVirtualGroupAssignmentAlgorithm, the topology assignment is not deterministic because it only uses instance counts within fault zones as a decider of zone weight. However, when multiple fault zones have the same number of instances, the fault zone that gets picked through a priority queue depends on the internal implementation on the order in which the fault zones were added to the priority queue, and the Java version that is being used. The impact of this is that service restarts could lead to a different virtual topology grouping and that triggers data rebalance.Tests
TestFaultZoneBasedVirtualGroupAssignment#testDeterministicVirtualZoneAssignment(List the names of added unit/integration tests)
(If CI test fails due to known issue, please specify the issue and test PR locally. Then copy & paste the result of "mvn test" to here.)
Changes that Break Backward Compatibility (Optional)
(Consider including all behavior changes for public methods or API. Also include these changes in merge description so that other developers are aware of these changes. This allows them to make relevant code changes in feature branches accounting for the new method/API behavior.)
Documentation (Optional)
(Link the GitHub wiki you added)
Commits
Code Quality
(helix-style-intellij.xml if IntelliJ IDE is used)