Since the cache has started on Machine B already, it won't initiate another state transfer from other members when re-joining the group since it can be expensive operation. If you stop and start the cache on Machine B (say, from JMX console via MBean service), then it should sync up.
But I will discuss with Bela on this maybe adding this as an option.
thanks for your answer. It would be nice to have such an option. Because otherwise we're getting problems with data inconsistency.
To do a workaround with stopping and starting the cache in such cases automatically, we first should know when a machine has no connection to the cluster anymore to react to it.
Is there some kind of function that is triggered when the clusternode-memberlist is changed (I mean when the viewAccepted()-message is displayed)?
Thanks in advance,
What you essentially want is a state-merge function after e.g. a network partition. This is actually on the roadmap, but it involves asking you (the application) how to merge 2 (potentially) different substates back into one. We *cannot* just take the union of the 2 substates, because an application may want to do this differently.
The final solution will definitely involve a callback into the application to resolve this, probably we also ship with some default strategies.