ehcache.xml

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

<!--
CacheManager Configuration
==========================
An ehcache.xml corresponds to a single CacheManager.

See instructions below or the ehcache schema (ehcache.xsd) on how to configure.

System property tokens can be specified in this file which are replaced when the configuration
is loaded. For example multicastGroupPort=${multicastGroupPort} can be replaced with the
System property either from an environment variable or a system property specified with a
command line switch such as -DmulticastGroupPort=4446. Another example, useful for Terracotta
server based deployments is <terracottaConfig url="${serverAndPort}"/ and specify a command line
switch of -Dserver36:9510

The attributes of <ehcache> are:
* name - an optional name for the CacheManager.  The name is optional and primarily used
for documentation or to distinguish Terracotta clustered cache state.  With Terracotta
clustered caches, a combination of CacheManager name and cache name uniquely identify a
particular cache store in the Terracotta clustered memory.
* updateCheck - an optional boolean flag specifying whether this CacheManager should check
for new versions of Ehcache over the Internet.  If not specified, updateCheck="true".
* dynamicConfig - an optional setting that can be used to disable dynamic configuration of caches
associated with this CacheManager.  By default this is set to true - i.e. dynamic configuration
is enabled.  Dynamically configurable caches can have their TTI, TTL and maximum disk and
in-memory capacity changed at runtime through the cache's configuration object.
* monitoring - an optional setting that determines whether the CacheManager should
automatically register the SampledCacheMBean with the system MBean server.

Currently, this monitoring is only useful when using Terracotta clustering and using the
Terracotta Developer Console. With the "autodetect" value, the presence of Terracotta clustering
will be detected and monitoring, via the Developer Console, will be enabled. Other allowed values
are "on" and "off".  The default is "autodetect". This setting does not perform any function when
used with JMX monitors.

* maxBytesLocalHeap - optional setting that constraints the memory usage of the Caches managed by the CacheManager
to use at most the specified number of bytes of the local VM's heap.
* maxBytesLocalOffHeap - optional setting that constraints the offHeap usage of the Caches managed by the CacheManager
to use at most the specified number of bytes of the local VM's offHeap memory.
* maxBytesLocalDisk - optional setting that constraints the disk usage of the Caches managed by the CacheManager
to use at most the specified number of bytes of the local disk.

These settings let you define "resource pools", caches will share. For instance setting maxBytesLocalHeap to 100M, will result in
all caches sharing 100 MegaBytes of ram. The CacheManager will balance these 100 MB across all caches based on their respective usage
patterns. You can allocate a precise amount of bytes to a particular cache by setting the appropriate maxBytes* attribute for that cache.
That amount will be subtracted from the CacheManager pools, so that if a cache a specified 30M requirement, the other caches will share
the remaining 70M.

Also, specifying a maxBytesLocalOffHeap at the CacheManager level will result in overflowToOffHeap to be true by default. If you don't want
a specific cache to overflow to off heap, you'll have to set overflowToOffHeap="false" explicitly

Here is an example of CacheManager level resource tuning, which will use up to 400M of heap and 2G of offHeap:

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="ehcache.xsd"
         updateCheck="true" monitoring="autodetect"
         dynamicConfig="true" maxBytesLocalHeap="400M" maxBytesLocalOffHeap="2G">

-->
<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="ehcache.xsd"
         updateCheck="false" monitoring="autodetect"
         dynamicConfig="true">

    <!--
    Management Rest Service configuration
    =====================================
    
    The managementRESTService element is optional.  By default the REST service that exposes monitoring and
    management features for the caches within the cache manager is disabled.  Enabling this feature will
    affect cache performance.
    
    The 'bind' attribute defaults to "0.0.0.0:9888" and sets the IP Address and Port to bind the web service
    to.  "0.0.0.0" binds to all local addresses / network interfaces.

    If you provide the 'securityServiceLocation' attribute, this will also enable authentication and other
    security measures on the REST service - which are only available for the enterprise-edition of the
    service.  The location should be the URL to the Terracotta Management Server that is being used to
    manage the ehcache instance. Enabling security requires that the management REST service be provided with
    a terracotta keychain in the default location ${user.home}/.tc/mgmt/keychain or as defined by the system property
    com.tc.management.keychain.file. The keychain is expected to hold a secret shared by the management client
    and keyed with this REST service's URI.

    Related to the the enterprise-edition security setup is the 'securityServiceTimeout' attribute. Setting this
    value will allow adjustment of the connection timeout to the security service location. The default value is
    5000 millis.

    If the 'sslEnabled' attribute is set to true, this will enable a non-blocking ssl connection to the management
    REST service. Turning this ssl connection on requires an identity store be provided at the default location
    ${user.home}/.tc/mgmt/keystore and that the JKS passphrase be included in the REST service keychain, keyed with
    the identity store file URI, or that the keystore and passphrase be identified with the ssl system properties
    javax.net.ssl.keyStore and javax.net.ssl.keyStorePassword.

    The 'needClientAuth' attribute requires ssl client certificate authorization if the 'sslEnabled' attribute has been
    set to true. Otherwise, it will be ignored.  Setting this attribute to true will require that the client's
    identity is imported as trusted into a truststore which is provided in the default location
    ${user.home}/.tc/mgmt/keystore and that the JKS passphrase be included in the REST service keychain, keyed with
    the trust store file URI, or that the truststore and passphrase be identified with the ssl system properties
    javax.net.ssl.trustStore and javax.net.ssl.trustStorePassword.

    Finally, several attributes exist to configure sampling history.

    - 'sampleHistorySize' allows the configuration of how many statistical samples will be kept in memory for
    each cache. The default value is set to 30.
    - 'sampleIntervalSeconds' allows the configuration of how often cache statistics will be obtained in seconds.
    The default value is set to 1 second.
    - 'sampleSearchIntervalSeconds' allows the configuration of how often cache seach statistics will be obtained in
    seconds. The default value is set to 10 seconds.

    examples:
    
    <managementRESTService enabled="true" bind="0.0.0.0:9888" />

    <managementRESTService enabled="true" securityServiceLocation="http://localhost:9889/tmc/api/assertIdentity"  />
    
     -->
    
    <!--
    DiskStore configuration
    =======================

    The diskStore element is optional. To turn off disk store path creation, comment out the diskStore
    element below.

    Configure it if you have disk persistence enabled for any cache or if you use
    unclustered indexed search.

    If it is not configured, and a cache is created which requires a disk store, a warning will be
     issued and java.io.tmpdir will automatically be used.

    diskStore has only one attribute - "path". It is the path to the directory where
    any required disk files will be created.

    If the path is one of the following Java System Property it is replaced by its value in the
    running VM. For backward compatibility these should be specified without being enclosed in the ${token}
    replacement syntax.

    The following properties are translated:
    * user.home - User's home directory
    * user.dir - User's current working directory
    * java.io.tmpdir - Default temp file path
    * ehcache.disk.store.dir - A system property you would normally specify on the command line
      e.g. java -Dehcache.disk.store.dir=/u01/myapp/diskdir ...

    Subdirectories can be specified below the property e.g. java.io.tmpdir/one

    -->
    <!-- <diskStore path="java.io.tmpdir"/> -->

    <!--
    TransactionManagerLookup configuration
    ======================================
    This class is used by ehcache to lookup the JTA TransactionManager use in the application
    using an XA enabled ehcache. If no class is specified then DefaultTransactionManagerLookup
    will find the TransactionManager in the following order

     *GenericJNDI (i.e. jboss, where the property jndiName controls the name of the
                    TransactionManager object to look up)
     *Bitronix
     *Atomikos

    You can provide you own lookup class that implements the
    net.sf.ehcache.transaction.manager.TransactionManagerLookup interface.
    -->

    <transactionManagerLookup class="net.sf.ehcache.transaction.manager.DefaultTransactionManagerLookup"
                              properties="jndiName=java:/TransactionManager" propertySeparator=";"/>


    <!--
    CacheManagerEventListener
    =========================
    Specifies a CacheManagerEventListenerFactory which is notified when Caches are added
    or removed from the CacheManager.

    The attributes of CacheManagerEventListenerFactory are:
    * class - a fully qualified factory class name
    * properties - comma separated properties having meaning only to the factory.

    Sets the fully qualified class name to be registered as the CacheManager event listener.

    The events include:
    * adding a Cache
    * removing a Cache

    Callbacks to listener methods are synchronous and unsynchronized. It is the responsibility
    of the implementer to safely handle the potential performance and thread safety issues
    depending on what their listener is doing.

    If no class is specified, no listener is created. There is no default.
    -->
    <cacheManagerEventListenerFactory class="" properties=""/>


    <!--
    CacheManagerPeerProvider
    ========================
    (For distributed operation)

    Specifies a CacheManagerPeerProviderFactory which will be used to create a
    CacheManagerPeerProvider, which discovers other CacheManagers in the cluster.

    One or more providers can be configured. The first one in the ehcache.xml is the default, which is used
    for replication and bootstrapping.

    The attributes of cacheManagerPeerProviderFactory are:
    * class - a fully qualified factory class name
    * properties - comma separated properties having meaning only to the factory.

    Providers are available for RMI, JGroups and JMS as shown following.

    RMICacheManagerPeerProvider
    +++++++++++++++++++++++++++

    Ehcache comes with a built-in RMI-based distribution system with two means of discovery of
    CacheManager peers participating in the cluster:
    * automatic, using a multicast group. This one automatically discovers peers and detects
      changes such as peers entering and leaving the group
    * manual, using manual rmiURL configuration. A hardcoded list of peers is provided at
      configuration time.

    Configuring Automatic Discovery:
    Automatic discovery is configured as per the following example:
    <cacheManagerPeerProviderFactory
                        class="net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
                        properties="hostName=fully_qualified_hostname_or_ip,
                                    peerDiscovery=automatic, multicastGroupAddress=230.0.0.1,
                                    multicastGroupPort=4446, timeToLive=32"/>

    Valid properties are:
    * peerDiscovery (mandatory) - specify "automatic"
    * multicastGroupAddress (mandatory) - specify a valid multicast group address
    * multicastGroupPort (mandatory) - specify a dedicated port for the multicast heartbeat
      traffic
    * timeToLive - specify a value between 0 and 255 which determines how far the packets will
      propagate.

      By convention, the restrictions are:
      0   - the same host
      1   - the same subnet
      32  - the same site
      64  - the same region
      128 - the same continent
      255 - unrestricted

     * hostName - the hostname or IP of the interface to be used for sending and receiving multicast
       packets (relevant to multi-homed hosts only)

    Configuring Manual Discovery:
    Manual discovery requires a unique configuration per host. It is contains a list of rmiURLs for
    the peers, other than itself. So, if we have server1, server2 and server3 the configuration will
    be:

    In server1's configuration:
    <cacheManagerPeerProviderFactory class=
                          "net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
                          properties="peerDiscovery=manual,
                          rmiUrls=//server2:40000/sampleCache1|//server3:40000/sampleCache1
                          | //server2:40000/sampleCache2|//server3:40000/sampleCache2"
                          propertySeparator="," />

    In server2's configuration:
    <cacheManagerPeerProviderFactory class=
                          "net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
                          properties="peerDiscovery=manual,
                          rmiUrls=//server1:40000/sampleCache1|//server3:40000/sampleCache1
                          | //server1:40000/sampleCache2|//server3:40000/sampleCache2"
                          propertySeparator="," />

    In server3's configuration:
    <cacheManagerPeerProviderFactory class=
                          "net.sf.ehcache.distribution.RMICacheManagerPeerProviderFactory"
                          properties="peerDiscovery=manual,
                          rmiUrls=//server1:40000/sampleCache1|//server2:40000/sampleCache1
                          | //server1:40000/sampleCache2|//server2:40000/sampleCache2"
                          propertySeparator="," />


    Valid properties are:
    * peerDiscovery (mandatory) - specify "manual"
    * rmiUrls (mandatory) - specify a pipe separated list of rmiUrls, in the form
                            //hostname:port
    * hostname (optional) - the hostname is the hostname of the remote CacheManager peer. The port is the listening
      port of the RMICacheManagerPeerListener of the remote CacheManager peer.

    JGroupsCacheManagerPeerProvider
    +++++++++++++++++++++++++++++++
    <cacheManagerPeerProviderFactory
         class="net.sf.ehcache.distribution.jgroups.JGroupsCacheManagerPeerProviderFactory"
         properties="channel=ehcache^connect=UDP(mcast_addr=231.12.21.132;mcast_port=45566;ip_ttl=32;
         mcast_send_buf_size=150000;mcast_recv_buf_size=80000):
         PING(timeout=2000;num_initial_members=6):
         MERGE2(min_interval=5000;max_interval=10000):
         FD_SOCK:VERIFY_SUSPECT(timeout=1500):
         pbcast.NAKACK(gc_lag=10;retransmit_timeout=3000):
         UNICAST(timeout=5000):
         pbcast.STABLE(desired_avg_gossip=20000):
         FRAG:
         pbcast.GMS(join_timeout=5000;join_retry_timeout=2000;shun=false;print_local_addr=false)"
         propertySeparator="^"
     />
     JGroups configuration is done by providing a connect string using connect= as in the above example which uses
     multicast, or since version 1.4, a file= to specify the location of a JGroups configuration file.

     If neither a connect or file property is specified, the default JGroups JChannel will be used.

     Multiple JGroups clusters may be run on the same network by specifying a different CacheManager name. The name
     is used as the cluster name.

     Since version 1.4 you can specify a channelName to avoid conflicts.


    JMSCacheManagerPeerProviderFactory
    ++++++++++++++++++++++++++++++++++
    <cacheManagerPeerProviderFactory
            class="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory"
            properties="..."
            propertySeparator=","
            />

    The JMS PeerProviderFactory uses JNDI to maintain message queue independence. Refer to the manual for full configuration
    examples using ActiveMQ and Open Message Queue.

    Valid properties are:
    * initialContextFactoryName (mandatory) - the name of the factory used to create the message queue initial context.
    * providerURL (mandatory) - the JNDI configuration information for the service provider to use.
    * topicConnectionFactoryBindingName (mandatory) - the JNDI binding name for the TopicConnectionFactory
    * topicBindingName (mandatory) - the JNDI binding name for the topic name
    * getQueueBindingName (mandatory only if using jmsCacheLoader) - the JNDI binding name for the queue name
    * securityPrincipalName - the JNDI java.naming.security.principal
    * securityCredentials - the JNDI java.naming.security.credentials
    * urlPkgPrefixes - the JNDI java.naming.factory.url.pkgs
    * userName - the user name to use when creating the TopicConnection to the Message Queue
    * password - the password to use when creating the TopicConnection to the Message Queue
    * acknowledgementMode - the JMS Acknowledgement mode for both publisher and subscriber. The available choices are
                            AUTO_ACKNOWLEDGE, DUPS_OK_ACKNOWLEDGE and SESSION_TRANSACTED. The default is AUTO_ACKNOWLEDGE.
    -->
<!-- 	<cacheManagerPeerProviderFactory -->
<!--             class="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory" -->
<!--             properties="initialContextFactoryName=au.com.sixtree.xref.cache.EHCacheActiveMQInitialContextFactory, -->
<!-- 			providerURL=tcp://localhost:61616, -->
<!-- 			userName=admin,password=admin,listenToTopic=true,acknowledgementMode=AUTO_ACKNOWLEDGE, -->
<!-- 			replicationTopicConnectionFactoryBindingName=topicConnectionFactory, -->
<!-- 			replicationTopicBindingName=ehcachetopic, -->
<!-- 			getQueueConnectionFactoryBindingName=queueConnectionFactory, -->
<!-- 			getQueueBindingName=ehcachequeue" -->
<!--             propertySeparator="," -->
<!--     /> -->
	<cacheManagerPeerProviderFactory
            class="net.sf.ehcache.distribution.jms.JMSCacheManagerPeerProviderFactory"
            properties="
            initialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory,
			providerURL=tcp://localhost:61616,
			userName=admin,password=admin,listenToTopic=true,acknowledgementMode=AUTO_ACKNOWLEDGE,
 			replicationTopicConnectionFactoryBindingName=TopicConnectionFactory,
			replicationTopicBindingName=dynamicTopics/ehcachetopicx,
 			getQueueConnectionFactoryBindingName=QueueConnectionFactory,
			getQueueBindingName=dynamicQueues/ehcachequeuex"
            propertySeparator=","
    />

    <!--
    Default Cache configuration. These settings will be applied to caches
    created programmatically using CacheManager.add(String cacheName).
    This element is optional, and using CacheManager.add(String cacheName) when
    its not present will throw CacheException

    The defaultCache has an implicit name "default" which is a reserved cache name.
        <persistence strategy="localTempSwap"/>
    -->
    <defaultCache
            maxEntriesLocalHeap="10000"
            eternal="false"
            timeToIdleSeconds="120"
            timeToLiveSeconds="120"
            diskSpoolBufferSizeMB="30"
            maxEntriesLocalDisk="10000000"
            diskExpiryThreadIntervalSeconds="120"
            memoryStoreEvictionPolicy="LRU">
    </defaultCache>

    <!--
    Viva Customer cache.
    This cache contains a maximum in memory of 10000 elements, and will expire
    an element if it is idle for more than 5 minutes and lives for more than
    10 minutes.

    If there are more than 10000 elements it will overflow to the
    disk cache, which in this configuration will go to wherever java.io.tmp is
    defined on your system. On a standard Linux system this will be /tmp"
    -->
    <cache name="viva:customer"
           maxEntriesLocalHeap="10000"           
	   overflowToDisk="false" 
	   diskPersistent="false"
           eternal="false"
           diskSpoolBufferSizeMB="20"
           timeToIdleSeconds="420"
           timeToLiveSeconds="600"
           memoryStoreEvictionPolicy="LFU"
           transactionalMode="off">
	   <cacheEventListenerFactory
              class="net.sf.ehcache.distribution.jms.JMSCacheReplicatorFactory"
              properties="replicateAsynchronously=true, replicatePuts=true,
             replicateUpdates=true, replicateUpdatesViaCopy=true,
             replicateRemovals=false, loaderArgument=viva:customer"
              propertySeparator=","/>
           <cacheLoaderFactory class="net.sf.ehcache.distribution.jms.JMSCacheLoaderFactory"
              properties="
            connectionFactoryNames=replicationTopicConnectionFactoryBindingName,
            initialContextFactoryName=org.apache.activemq.jndi.ActiveMQInitialContextFactory,
            providerURL=tcp://localhost:61616,loaderArgument=viva:customer,
			userName=admin,password=admin,acknowledgementMode=AUTO_ACKNOWLEDGE,
			replicationTopicConnectionFactoryBindingName=TopicConnectionFactory,
			replicationTopicBindingName=dynamicTopics/ehcachetopic,
			getQueueConnectionFactoryBindingName=QueueConnectionFactory,
			getQueueBindingName=dynamicQueues/ehcachequeue,
            timeoutMillis=20000,
            defaultLoaderArgument=viva:customer" propertySeparator="," />
<!--            <cacheLoaderFactory class="net.sf.ehcache.distribution.jms.JMSCacheLoaderFactory" -->
<!--               properties="initialContextFactoryName=au.com.sixtree.xref.cache.EHCacheActiveMQInitialContextFactory, -->
<!--                         providerURL=tcp://localhost:61616,loaderArgument=viva:customer, -->
<!-- 			userName=admin,password=admin,acknowledgementMode=AUTO_ACKNOWLEDGE, -->
<!-- 			replicationTopicConnectionFactoryBindingName=topicConnectionFactory, -->
<!-- 			replicationTopicBindingName=ehcachetopic, -->
<!-- 			getQueueConnectionFactoryBindingName=queueConnectionFactory, -->
<!-- 			getQueueBindingName=ehcachequeue, -->
<!--                         timeoutMillis=20000,defaultLoaderArgument=viva:customer" propertySeparator="," /> -->
    </cache>
</ehcache>