eXo Platform 3.5

## Chapter 23. JBoss Cache configuration

This chapter will show you how to use and configure Jboss Cache in the clustered environment. Also, you will know how to use a template-based configuration offered by eXo JCR for JBoss Cache instances.

## JBoss cache configuration for indexer, lock manager and data container

Each mentioned components uses instances of JBoss Cache product for caching in clustered environment. So every element has its own transport and has to be configured in a proper way. As usual, workspaces have similar configuration but with different cluster-names and may-be some other parameters. The simplest way to configure them is to define their own configuration files for each component in each workspace:

    <property name="jbosscache-configuration" value="conf/standalone/test-jbosscache-lock-db1-ws1.xml" />

But if there are few workspaces, configuring them in such a way can be painful and hard-manageable. eXo JCR offers a template-based configuration for JBoss Cache instances. You can have one template for Lock Manager, one for Indexer and one for data container and use them in all the workspaces, defining the map of substitution parameters in a main configuration file. Just simply define ${jbosscache-<parameter name>} inside xml-template and list correct value in JCR configuration file just below "jbosscache-configuration", as shown:

Template:

    ...

    <clustering mode="replication" clusterName="${jbosscache-cluster-name}">

      <stateRetrieval timeout="20000" fetchInMemoryState="false" />

    ...

and JCR configuration file:

    ...

    <property name="jbosscache-configuration" value="jar:/conf/portal/jbosscache-lock.xml" />

    <property name="jbosscache-cluster-name" value="JCR-cluster-locks-db1-ws" />

    ...

## JGroups configuration

JGroups is used by JBoss Cache for network communications and transport in a clustered environment. If property "jgroups-configuration" is defined in component configuration, it will be injected into the JBoss Cache instance on startup.

    <property name="jgroups-configuration" value="your/path/to/modified-udp.xml" />

As mentioned above, each component (lock manager, data container and query handler) for each workspace requires its own clustered environment. In other words, they have their own clusters with unique names. By default, each cluster should perform multi-casts on a separate port. This configuration leads to much unnecessary overhead on cluster. That's why JGroups offers multiplexer feature, providing ability to use one single channel for set of clusters. This feature reduces network overheads and increase performance and stability of application. To enable multiplexer stack, you should define appropriate configuration file (upd-mux.xml is pre-shipped one with eXo JCR) and set "jgroups-multiplexer-stack" to "true".

    <property name="jgroups-configuration" value="jar:/conf/portal/udp-mux.xml" />

    <property name="jgroups-multiplexer-stack" value="true" />

It is now highly recommended to use the shared transport instead of the multiplexer, to do so simply disable the multiplexer stack in the configuration of each component by setting the property jgroups-multiplexer-stack to false then you will need to ensure that the format of your jgroups configuration is not anymore a jgroups stack definitions but a normal configuration and finally you will need to set the property singleton_name of your JGroups configuration to a unique name (this name must not be the same from one portal container to another).

    <property name="jgroups-configuration" value="jar:/conf/portal/udp-mux.xml" />

    <property name="jgroups-multiplexer-stack" value="false" />

## Allow to share JBoss Cache instances

A JBoss Cache instance is quite resource consuming and by default we will have 3 JBoss Cache instances (one instance for the indexer, one for the lock manager and one for the data container) for each workspace, so if you intend to have a lot of workspaces it could make sense to decide to share one JBoss Cache instance with several cache instances of the same type (i.e. indexer, lock manager or data container). This feature is disabled by default and can be enabled at component configuration level (i.e. indexer configuration, lock manager configuration and/or data container configuration) by setting the property "jbosscache-shareable" to true as below:

    <property name="jbosscache-shareable" value="true" />

Once enabled this feature will allow the JBoss Cache instance used by the component to be re-used by another components of the same type (i.e. indexer, lock manager or data container) with the exact same JBoss Cache configuration (except the eviction configuration that cans be different), which means that all the parameters of type ${jbosscache-<parameter name>} must be identical between the components of same type of different workspaces. In other words, if we use the same values for the parameters of type ${jbosscache-<parameter name>} in each workspace, we will have only 3 JBoss Cache instances (one instance for the indexer, one for the lock manager and one for the data container) used whatever the total amount of workspaces defined.

## Shipped JBoss Cache configuration templates

eXo JCR implementation is shipped with ready-to-use JBoss Cache configuration templates for JCR's components. They are situated in application package in /conf/porta/ folder.

### Data container template

Data container template is "jbosscache-data.xml":

    <?xml version="1.0" encoding="UTF-8"?>

    <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">

       <locking useLockStriping="false" concurrencyLevel="500" lockParentForChildInsertRemove="false"

          lockAcquisitionTimeout="20000" />

       <clustering mode="replication" clusterName="${jbosscache-cluster-name}">

          <stateRetrieval timeout="20000" fetchInMemoryState="false" />

          <sync />

       </clustering>

       <!-- Eviction configuration -->

       <eviction wakeUpInterval="5000">

          <default algorithmClass="org.jboss.cache.eviction.ExpirationAlgorithm"

             actionPolicyClass="org.exoplatform.services.jcr.impl.dataflow.persistent.jbosscache.ParentNodeEvictionActionPolicy"

             eventQueueSize="1000000">

             <property name="maxNodes" value="1000000" />

             <property name="warnNoExpirationKey" value="false" />

          </default>

       </eviction>

    </jbosscache>

Variable
jbosscache-cluster-name

### Lock manager template

It's template name is "jbosscache-lock.xml"

    <?xml version="1.0" encoding="UTF-8"?>

    <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">

       <locking useLockStriping="false" concurrencyLevel="500" lockParentForChildInsertRemove="false"

          lockAcquisitionTimeout="20000" />

       <clustering mode="replication" clusterName="${jbosscache-cluster-name}">

          <stateRetrieval timeout="20000" fetchInMemoryState="false" />

          <sync />

       </clustering>

       <loaders passivation="false" shared="true">

          <preload>

             <node fqn="/" />

          </preload>

          <loader class="org.exoplatform.services.jcr.impl.core.lock.jbosscache.JDBCCacheLoader" async="false" fetchPersistentState="false"

             ignoreModifications="false" purgeOnStartup="false">

             <properties>

                cache.jdbc.table.name=${jbosscache-cl-cache.jdbc.table.name}

                cache.jdbc.table.create=${jbosscache-cl-cache.jdbc.table.create}

                cache.jdbc.table.drop=${jbosscache-cl-cache.jdbc.table.drop}

                cache.jdbc.table.primarykey=${jbosscache-cl-cache.jdbc.table.primarykey}

                cache.jdbc.fqn.column=${jbosscache-cl-cache.jdbc.fqn.column}

                cache.jdbc.fqn.type=${jbosscache-cl-cache.jdbc.fqn.type}

                cache.jdbc.node.column=${jbosscache-cl-cache.jdbc.node.column}

                cache.jdbc.node.type=${jbosscache-cl-cache.jdbc.node.type}

                cache.jdbc.parent.column=${jbosscache-cl-cache.jdbc.parent.column}

                cache.jdbc.datasource=${jbosscache-cl-cache.jdbc.datasource}

             </properties>

          </loader>

       </loaders>

    </jbosscache>

### Note

To prevent any consistency issue regarding the lock data please ensure that your cache loader is org.exoplatform.services.jcr.impl.core.lock.jbosscache.JDBCCacheLoader and that your database engine is transactional.

Variable
jbosscache-cluster-name
jbosscache-cl-cache.jdbc.table.name
jbosscache-cl-cache.jdbc.table.create
jbosscache-cl-cache.jdbc.table.drop
jbosscache-cl-cache.jdbc.table.primarykey
jbosscache-cl-cache.jdbc.fqn.column
jbosscache-cl-cache.jdbc.fqn.type
jbosscache-cl-cache.jdbc.node.column
jbosscache-cl-cache.jdbc.node.type
jbosscache-cl-cache.jdbc.parent.column
jbosscache-cl-cache.jdbc.datasource

### Query handler (indexer) template

Have a look at "jbosscache-indexer.xml"

    <?xml version="1.0" encoding="UTF-8"?>

    <jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:jboss:jbosscache-core:config:3.1">

       <locking useLockStriping="false" concurrencyLevel="500" lockParentForChildInsertRemove="false"

          lockAcquisitionTimeout="20000" />

       <clustering mode="replication" clusterName="${jbosscache-cluster-name}">

          <stateRetrieval timeout="20000" fetchInMemoryState="false" />

          <sync />

       </clustering>

    </jbosscache>

Variable
jbosscache-cluster-name

Copyright © 2009-2012. All rights reserved. eXo Platform SAS