Re: [infinispan-dev] Asymmetric caches and manual rehashing design

On Wed, Sep 28, 2011 at 12:59 PM, Bela Ban <bban(a)redhat.com&gt; wrote: Indeed, one member could disable view delivery for the entire cluster. The main scenario I had in mind for this was stopping the entire cluster. A good rebalancing policy might handle such cases automatically, so I'm not 100% sure we need this. I'm not sure what benefits you would get from joining the cache view but not receiving state compared to not sending the join request at all. Non-members are allowed to send/receive commands, so in the future we could even have separate "server" nodes (that join the cache view) and "client" nodes (joining the JGroups cluster to send commands, but not the cache view and so not holding any data except L1). My idea was that the cache view was a representation of the caches that are able to service requests, so it doesn't make sense to include in the view caches that don't hold data. As a practical note, if we add nodes to the consistent hash as they come along, a key will have one set of owners if written to before the join and another set of owner if written to after the join. How should another node determine the current location of the key, especially considering that there can be many view changes before rebalancing is triggerred? Nope, this doesn't have anything to do with transactional caches, instead it is all about computing the owner that will push the key during the rebalance operation. In order to do it deterministically we need to have a common "last good consistent hash" for the last rebalance that finished successfully, and each node must determine if it should push a key or not based on that last good CH. A rebalance operation can also fail for various reasons (e.g. the coordinator died). If that happens the new owners won't have all the state, so they should not receive requests for the state that they would have had in the pending CH. If view installation wasn't tied to state transfer then we'd have to keep yet the last rebalanced view somewhere else. We would hold the "last pending view" (pending rebalance, that is) in the CacheViewsManager and the "last rebalanced view" in another component, and that component would have it's own mechanism for synchronizing the "last rebalanced view" among cache members. So I think the 2PC approach in CacheViewsManager actually simplifies things. Cheers Dan