[
https://issues.jboss.org/browse/ISPN-493?page=com.atlassian.jira.plugin.s...
]
Manik Surtani commented on ISPN-493:
------------------------------------
This has been fixed to a degree, and we now have:
* Concurrent pulls of state during a leave or join from concurrent providers
* Robust enqueueing and retrying on receivers
* Accurate transaction logging on state providers, including flushing of remote
transaction logs
* Blocking new transactions from starting on receivers during a read, to prevent
interleaving and overwriting
In addition to consistency, this benefits performance a good deal as well since joins now
happen a lot faster.
Harden rehash leave process
---------------------------
Key: ISPN-493
URL:
https://issues.jboss.org/browse/ISPN-493
Project: Infinispan
Issue Type: Task
Affects Versions: 4.0.0.Final, 4.1.0.BETA2
Reporter: Vladimir Blagojevic
Assignee: Manik Surtani
Priority: Critical
Fix For: 4.2.1.CR2, 4.2.1.Final
We need to make sure that leave rehash process properly handles massive and rapid node
failure.
Massive failures:
JGroups detects multiple node failures and pushes up to Infinispan views that are more
"volatile" than we currently assumed (only one member at the time can leave).
For example, if we have view V1={A,B,C,D,E} and massive failure causes {C,D,E} to fail,
JGroups failure detection and GMS are going to install a view V2={A,B} to surviving
members. LeaveTask does not handle this scenario.
Rapid node failure:
We need to revisit how LeaveTasks are queued up and executed/canceled during rapid node
failures. Do we always cancel currently running leave tasks? At what stage are we allowed
to cancel it and at what stage of a leave tasks is it better to wait for a completion of a
task.
--
This message is automatically generated by JIRA.
For more information on JIRA, see:
http://www.atlassian.com/software/jira