[ https://issues.jboss.org/browse/ISPN-4587?page=com.atlassian.jira.plugin.... ] Dan Berindei updated ISPN-4587: ------------------------------- Description: Say we have a distributed cache \[A, B\] with {{numSegments = 1}} and {{numOwners = 2}}. The initial topology is _T_: currentCH = \{0: A B\}, pendingCH = null C joins, and A starts a rebalance. The topology is now _T + 1_: currentCH = \{0: A B\}, pendingCH = \{0: A C\} C now leaves, A updates the consistent hashes to remove it with a new topology _T + 2: currentCH = \{0: A B\}, pendingCH = \{0: A\} A doesn't need to receive any data, so the rebalance ends and the pending CH is installed as the current CH in topology _T + 3_: currentCH = \{0: A\}, pendingCH = null This algorithm is relatively easy to follow and implement, but it does result in reduced availability of the cache data. It would be better if topology _T + 2_ could re-add B as an owner in the pending CH. was: Say we have a distributed cache \[A, B\] with {{numSegments = 1}} and {{numOwners = 2}}. The initial topology is _T_: currentCH = {0: A B}, pendingCH = null C joins, and A starts a rebalance. The topology is now _T + 1_: currentCH = {0: A B}, pendingCH = {0: A C} C now leaves, A updates the consistent hashes to remove it with a new topology _T + 2: currentCH = {0: A B}, pendingCH = {0: A} A doesn't need to receive any data, so the rebalance ends and the pending CH is installed as the current CH in topology _T + 3_: currentCH = {0: A}, pendingCH = null This algorithm is relatively easy to follow and implement, but it does result in reduced availability of the cache data. It would be better if topology _T + 2_ could re-add B as an owner in the pending CH. -- This message was sent by Atlassian JIRA (v6.2.6#6264)