BalancedShardAllocator makes non-deterministic rebalance decisions #4867
Assignees
Labels
>bug
:Distributed/Distributed
A catch all label for anything in the Distributed Area. If you aren't sure, use this one.
v0.90.11
v1.0.0.RC2
v1.1.0
v2.0.0-beta1
Comments
ghost
assigned
s1monw
added a commit
that referenced
this issue
Jan 23, 2014
It happens to be the case that the iteration order of a HashMaps keyset might be different across runs. This can cause undeterministic results in shard balancing if weights are identical and multiple shards of the same index are eligable for relocation. This commit adds a tie-breaker based on the shard ID to prioritise the lowest shard ID. This also makes `AddIncrementallyTests#testAddNodesAndIndices` reproducible. Closes #4867
s1monw
added a commit
that referenced
this issue
Jan 23, 2014
It happens to be the case that the iteration order of a HashMaps keyset might be different across runs. This can cause undeterministic results in shard balancing if weights are identical and multiple shards of the same index are eligable for relocation. This commit adds a tie-breaker based on the shard ID to prioritise the lowest shard ID. This also makes `AddIncrementallyTests#testAddNodesAndIndices` reproducible. Closes #4867
s1monw
added a commit
that referenced
this issue
Jan 23, 2014
It happens to be the case that the iteration order of a HashMaps keyset might be different across runs. This can cause undeterministic results in shard balancing if weights are identical and multiple shards of the same index are eligable for relocation. This commit adds a tie-breaker based on the shard ID to prioritise the lowest shard ID. This also makes `AddIncrementallyTests#testAddNodesAndIndices` reproducible. Closes #4867
mute
pushed a commit
to mute/elasticsearch
that referenced
this issue
Jul 29, 2015
It happens to be the case that the iteration order of a HashMaps keyset might be different across runs. This can cause undeterministic results in shard balancing if weights are identical and multiple shards of the same index are eligable for relocation. This commit adds a tie-breaker based on the shard ID to prioritise the lowest shard ID. This also makes `AddIncrementallyTests#testAddNodesAndIndices` reproducible. Closes elastic#4867
mute
pushed a commit
to mute/elasticsearch
that referenced
this issue
Jul 29, 2015
It happens to be the case that the iteration order of a HashMaps keyset might be different across runs. This can cause undeterministic results in shard balancing if weights are identical and multiple shards of the same index are eligable for relocation. This commit adds a tie-breaker based on the shard ID to prioritise the lowest shard ID. This also makes `AddIncrementallyTests#testAddNodesAndIndices` reproducible. Closes elastic#4867
lcawl
added
:Distributed/Distributed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
NOTE: this is not a problem in production! It happens that the allocator iterates over the keys of a set which might be different across runs. This makes unittests non-reproducible. We should tie-break on the shard ID in that case.
The text was updated successfully, but these errors were encountered: