[
https://issues.jboss.org/browse/ISPN-2574?page=com.atlassian.jira.plugin....
]
Michal Linhard reopened ISPN-2574:
----------------------------------
Adrian please check out my test case:
https://github.com/mlinhard/infinispan/commit/8681c35c95aeba128ae28a1c2ab...
it doesn't work for current master.
the test scenario is a more simple one:
config: distribution, num owners 2
1. create cluster {A,B}, fill 1000 entries
2. join C
3. when B is about to send StateResponseCommand to C, fail B, never send the command
4. C should restart the state transfer and ask the same segments from A
5. cluster {A, C} will form with all segments properly backed up on both A and C
Beta4 didn't restart the state transfer which meant some entries weren't properly
transfered to C
Beta6 did this alright
current master again fails to restart the state transfer from A
Segment transfer not restarted if the owner fails
-------------------------------------------------
Key: ISPN-2574
URL:
https://issues.jboss.org/browse/ISPN-2574
Project: Infinispan
Issue Type: Bug
Components: State transfer
Affects Versions: 5.2.0.Beta4
Reporter: Radim Vansa
Assignee: Adrian Nistor
Priority: Critical
Fix For: 5.2.0.CR1
Imagine this situation in distributed cache with 3 owners:
1) The segment X is owned by nodes A, B, C
2) Node B fails -> CH_UPDATE and then REBALANCE_START are broadcasted
3) Node D starts transfer of segment X from C
4) Node C fails -> another CH_UPDATE is broadcasted
5) D handes the CH_UPDATE and removes the transfer of segment X from C, but does not
start another transfer from A
The {{addedSegments}} does not contain the restarted transfer, because all transfers from
write consistent hash are removed from it in the beginning - the segment is considered
received here although the transfer is still in progress.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:
http://www.atlassian.com/software/jira