CacheViewsManager implementation.
It uses {@link org.infinispan.commands.control.CacheViewControlCommand}s to organize the installation of cache views in two phases.
There are three phases in installing a cache view:
- A node wants to start or stop the cache, sending a REQUEST_JOIN or a REQUEST_LEAVE. A node leaving the JGroups cluster is interpreted as a REQUEST_LEAVE for all its caches. The request will be broadcast to all the cluster members, as all the nodes need to stop sending requests to the leavers.
- For join requests, the cache views manager will wait for a short period of time to allow other members to join.
- The coordinator then sends a PREPARE_VIEW to all the nodes that have the cache started (or starting). Any node can veto the view by throwing an exception in this phase.
- The coordinator sends a COMMIT_VIEW to all the nodes that have the cache started.
- If a node threw an exception during PREPARE_VIEW, the coordinator will send a ROLLBACK_VIEW instead.
After a configurable amount of time the coordinator may retry to install the view, but with a different view id (even if the members are the same; this makes it simpler to implement). Only the coordinator keeps the information about which nodes have requested to join, so when the coordinator changes the new coordinator will have to request state from all the members using the RECOVER_VIEW command. This also happens after a merge, even if the new coordinator was a coordinator in one of the partitions. For a full description of the view recovery algorithm see {@link #recoverViews()}
@author Dan Berindei <dan@infinispan.org>
@since 5.1