[infinispan-issues] [JBoss JIRA] (ISPN-4587) Re-add old owners in the pending CH when a node leaves during rebalance

[Dan Berindei (JIRA)]

     [ https://issues.jboss.org/browse/ISPN-4587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

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.



> Re-add old owners in the pending CH when a node leaves during rebalance
> -----------------------------------------------------------------------
>
>                 Key: ISPN-4587
>                 URL: https://issues.jboss.org/browse/ISPN-4587
>             Project: Infinispan
>          Issue Type: Enhancement
>      Security Level: Public(Everyone can see) 
>          Components: Core, State Transfer
>    Affects Versions: 7.0.0.Alpha5
>            Reporter: Dan Berindei
>            Assignee: Dan Berindei
>            Priority: Minor
>             Fix For: 7.0.0.Beta1
>
>
> 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)