Q1: yes

Q2: yes

Q3: If tou have fetchPersistentSate="true" then the cache store of A will be cleaned and all the data will be fetched from B and C.

Q4: true

Q5: that's what I would expect, perhs manik can confirm

Re:Q6, you should use preload="true", fetchPesistentState="true" and an  @ViewChanged lister. The listener will be called whenever a new member joins, with information(event) that contain the size of the cluster. Once the cluster has the desired state, it means that the whole cluster was started and you can inform your application about it.

HTH,

Mircea

Hi, a couple of more clarification questions. When is @ViewChanged
actually called, in case of a new node?

A) after JGroups view has
changed, o

B) after the new node is preloaded and state
transferred?

Good point. ViewChanged will signal jgroups join (A) and not "Node joined and cluster size is now n". I think this might be a bit more complex than I thought. I think a NodeJoined event would make perfect sense for this scenario. But as we don't have one, here is a workaround that I think will do the job: register an CacheStarted listener, that will be called once the local cache is fully started. N.B. this does not mean that cluster is formed, it might be that other caches are still joininig. Now, as the cache is started you can do cache.put(localAddress, "started"). Then, in a loop, do:

while (cacheManager.getMembers().size() < expectedClusterSize) {
  Thread.sleep(1000);

}
boolean clusterFormed = false;
for (Address addr:cacheManager.getMembers()) {
      if (cache.get(addr) == null) {
         clusterFormed = false;

      }

   }
}
//now inform you app that cluster was formed

Looking back, this looks a lot as a workaround, but it should do the job.

How are the overlapping
rehashing/state transfers managed. E.g. one node JVM crashes ->
rehashing/state transfers, the crashed node comes back to alive (e.g.
through automatic restart) before the rehashing/state transfer is
completed. What is the policy to manage this situation?

This is something that needs to be looked into in more details. I'll add a JIRA for it;