Infinispan Cache Container Configuration
Internal
Overview
As described in the Cache Container section of the Infinispan Concepts page, the <cache-container> element contains global configuration for a set of caches. The cache container global configuration defines global settings shared among all cache instances created for the respective cache container. Shared resources like thread pools, serialization/marshaling settings, transport and network settings are all part of global configuration.
<subsystem xmlns="urn:infinispan:server:core:6.4" default-cache-container="clustered"> <cache-container name="clustered" default-cache="default" statistics="true"> <transport executor="infinispan-transport" lock-timeout="60000"/> <distributed-cache name="default" ... /> <replicated-cache .../> </cache-container> ... </subsystem>
infinispan Subsystem Configuration
default-cache-container
The name of the cache container to use if no specific name is used
cache-container Configuration
name
The cache container name. Must be unique among other cache container names. Unless otherwise set up on the <transport> element (see below), it will become the JGroups cluster name for the clustered caches.
- If the <transport> sub-element attribute "cluster" is not defined, the cache container name will be used as the value of the JGroups group name, and that means each cache container will create its own JGroups channel instances, group, etc. They will share configuration, though. Ultimately, each cache container will maintain its own cluster, with a different coordinator, view, etc. It is possible, and quite probable, that different members of the cluster will be coordinators for different cache containers, and that complicates JGroups problems troubleshooting.
default-cache
The name of the default cache of the underlying cache container. It is not a required value.
For more details on Infinispan named and default cache, see Named Caches and Default Caches.
statistics
Statistics generation is useful in monitoring, but they may impact the performance. true by default.
listener-executor
Defines the executor used for asynchronous listener notifications.
start
The parameter indicates when the cache container starts, i.e. whether it will start "lazily" when requested or "eagerly" when the server starts up. Valid value: LAZY, EAGER.
aliases
A comma-separated list of aliases. Each alias must be unique among other aliases within the subsystem. They result in alias services being also made available ("service jboss.infinispan.ha-partition").
What is an alias and what is it useful for?
<transport>
Cache Configuration
Common Attributes
batching
Common Cache Configuration Elements
<expiration>
<distributed-cache ...> <expiration lifespan="86400000" max-idle="900000" interval="60000"/> </distributed-cache>
For more details about expiration, see:
Distributed Cache Configuration
owners
Represents the number of cluster-wide copies for each cache entry (the number includes the "first" copy, which otherwise can be thought of as the "original"). Default is 2 - so if no specific 'owners' number is configured, the default behavior is to store the original and one extra copy. Increasing this may increase reliability but with the cost of decreasing performance.
As an example, if owners is 1, for example, just one instance of the piece of data is maintained by the cluster, and it may not even be on the same node that handled the put request. If owners is 2, the key/value pair will be maintained on two nodes, and neither of them is necessarily the node that handled the put request.
Example of owners configuration:
<subsystem xmlns="urn:infinispan:server:core:6.4"> <cache-container name="clustered" ...> ... <distributed-cache name="dist-example" owners="2" ...> ... </distributed-cache> </cache-container> ... </subsystem>
Related operational metrics:
Replicated Cache Configuration
Invalidation Cache Configuration
Local Cache Configuration
Cache Store Configuration
Any of the above caches can be configured with one or more cache stores.
Any cache store supports the following common configuration attributes:
passivation
The default value is "false".
For related concepts see:
The default value is "false".
For related concepts see:
preload
The default value is "false".
For related concepts see:
fetch-state
Default "true".
If true, fetch persistent state when joining a cluster. If multiple cache stores are chained, only one of them can have this property enabled.
purge
Default "true".
singleton
Default "false".
If true, the singleton store cache store is enabled. SingletonStore is a delegating cache store used for situations when only one instance in a cluster should interact with the underlying store. Whenever any data comes in to some node it is always replicated (or distributed) so as to keep the caches in-memory states in sync; the coordinator, though, has the sole responsibility of pushing that state to disk. This functionality must be configured by setting the enabled attribute to true in all nodes. Only the coordinator of the cluster will persist data, but all nodes must have this configured to prevent others from persisting as well. You cannot configure a store as shared and singleton.
Cache stores supports the following embedded configuration elements: