Skip to content

Latest commit

 

History

History
33 lines (27 loc) · 2.5 KB

Clustered-cache-configuration-state.asciidoc

File metadata and controls

33 lines (27 loc) · 2.5 KB
Raw

Clustered cache configuration / state

Currently all members of a cluster manage their configuration, cache lifecycle and most of the state independently. This means that in order for a cache to be created across a cluster, each node must define its configuration locally and start it. There is also no validation that a cache configuration is compatible across nodes. Also, while some configuration attributes can be changed at runtime, this does not happen cluster-wide (although it might make sense for some configuration attributes to be asymmetric, e.g. capacity factor). Additionally, when new nodes join a running cluster, they should also start any clustered caches so that symmetry is maintained.

Implementation

  • Change the current behaviour of the GlobalStateManager, enabling it internally by default. Persistence of state will however continue to be enabled only if requested by the user.

  • The GlobalStateManager adds a ___state cache handled by the InternalCacheRegistry. This cache will contain both cache configurations (stored as strings using the Infinispan XML schema) and a list of running caches (do we need to store more state ?).

  • Cache configuration and lifecycle performed via the usual DefaultCacheManager API will continue to behave as it does currently (i.e. each node is independent).

  • Add a new API for managing clustered configuration and state (see below)

  • Allow configuration Attributes to be either Global or Local.

  • Implement a variant of equals (equalsIgnoreLocal ?) for Configuration objects to validate congruency ignoring local attributes.

  • Support the start configuration attribute for caches (which can be either LAZY or EAGER) so that EAGER caches are automatically started when the CacheManager is started.

  • When a node joins a cluster it retrieves the list of running caches from the state cache and starts them using the configuration from the state cache. The configuration coming from the state cache is validated against any local configuration which might be present in the DCM’s ConfigurationManager.

  • Modifying a Global configuration Attribute at runtime will propagate the change to all nodes.

API

Add a cluster() method to the DefaultCacheManager which returns a cluster-affecting implementation of the EmbeddedCacheManager interface. Methods such as defineConfiguration(), undefineConfiguration(), startCaches(), will affect the entire cluster. All other methods will be delegated to the underlying local DefaultCacheManager.