Infinispan Cache Container Configuration

Internal

• Infinispan Configuration

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?

Cache Configuration

Distributed Cache Configuration

numOwners

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. Increasing this may increase reliability but with the cost of decreasing performance.

As an example, if numOwners 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 numOwners 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.

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:

Infinispan Concepts - Cache Store Passivation

shared

The default value is "false".

For related concepts see:

Infinispan Concepts - Shared Cache Store

preload

The default value is "false".

For related concepts see:

Infinispan Concepts - Cache Store Preloading

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".

Infinispan Concepts - Cache Store Purge

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: