-
Bug
-
Resolution: Done
-
Critical
-
7.0.2.Final
Copied from ISPN-4444
If the CH_UPDATE command is delayed on the old owner, the new owners might update the key without the old owner knowing, and a locality check on the old owner won't help.
I remember one thing that struck me when reading the Raft algorithm was that they install configuration changes symmetrically, in 3 phases. We might need to do the same for our rebalance:
1. T0: read_ch=old, write_ch=old
2. start a rebalance
3. T1: read_ch=old, write_ch=old+new
4. new owners have all the data
5. T2: read_ch=new, write_ch=old+new
6. remove old cache entries and ignore further writes
7. T3: read_ch=new, write_ch=new
- causes
-
JBEAP-8958 RpcException: No successful response
- Closed
- is blocked by
-
ISPN-5046 PartitionHandling: split during commit can leave the cache inconsistent after merge
- Closed
- is incorporated by
-
ISPN-7958 Backports for 8.2.8.Final
- Closed
-
ISPN-7327 Backports for 8.2.7.Final
- Closed
- is related to
-
ISPN-4444 After state transfer, a node is able to read keys it no longer owns from its data container
- Closed
-
ISPN-5016 Specify and document cache consistency guarantees
- Closed
- relates to
-
ISPN-9028 Write-only segments should be invalidated during the READ_NEW phase
- Closed