Version 10

    Session affinity, large cluster, no replication, use of a far cache




    This page discusses the far cache concept in terms of "sessions".  The configuration below is not a supported configuration for http session replication in the JBoss Application Server, and will not necessarily work properly if implemented. Readers of this page should think of the concepts on this page in terms of how to manage cached data that is logically "owned" by one server in a cluster, but which needs to be available to other servers in case of a failover. An HttpSession is conceptually that kind of data, but meeting the servlet spec and the full set of expected behaviors of an HttpSession mean that a sophisticated integration layer is required on top of the JBoss Cache.  The current integration layer in JBoss AS will not work reliably with the configuration below.



    Manik Surtani (


    Use case


    You have a large cluster of application servers and the overhead of replicating state is high.  Network traffic and memory usage on each node is a problem and scaling is difficult.




    To use this pattern, you must:


    • Use a load balancer

    • Use sticky sessions

    • JBoss Cache 1.3.0 "Wasabi" and above




    JBoss Cache 1.3.0 has several features that can be used to help this scenario, specifically TCP or RMI based delegating cache loaders.


    Since sessions are sticky, there is often no need for each node in the cluster to have access to all session data.  As such, it is safe to switch off replication altogether - set CacheMode to LOCAL.  Immediate savings in replication traffic and memory overhead.


    But what happens if a node drops out and another node needs to take over the session data?  This is where the far cache comes in.  Each cache is configured with a TCP (or RMI) delegating cache loader, called a far cache.  This cache loader points to a dedicated host somewhere which acts as a large in-memory far cache.  Using (potentially asynchronous) cache loader semantics, each cache writes back to the far cache as a single backup store of data.



    As shown above, the far cache is implemented as a single, standalone instance of JBoss Cache with a TCP or RMI listener.  This can even be deployed as an MBean in JBoss Cache 1.3.0 (see JBoss Cache documentation for this).  The far cache can even be optionally backed by a JDBC cache loader to persist it's in-memory state.


    Sample configuration


    Configuring JBoss Cache on your cluster


    <?xml version="1.0" encoding="UTF-8"?>
        <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"></classpath>
        <mbean code="org.jboss.cache.TreeCache"
            <attribute name="TransactionManagerLookupClass">org.jboss.cache.DummyTransactionManagerLookup</attribute>
            <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
            <attribute name="CacheMode">LOCAL</attribute>
            <attribute name="UseReplQueue">false</attribute>
            <attribute name="LockAcquisitionTimeout">10000</attribute>
            <attribute name="UseMarshalling">false</attribute>
            <attribute name="CacheLoaderConfiguration">



    Deploying a TCP based far cache as an MBean in JBoss AS on a standalone 'far cache' node


    <?xml version="1.0" encoding="UTF-8"?>
       <classpath codebase="./lib" archives="jboss-cache.jar"></classpath>
       <mbean code="org.jboss.cache.loader.tcp.TcpCacheServer" name="jboss.cache:service=TcpCacheServer">
          <depends optional-attribute-name="Cache"
          <attribute name="BindAddress">${jboss.bind.address:localhost}</attribute>
          <attribute name="Port">7500</attribute>
          <attribute name="MBeanServerName"></attribute>
          <!--<attribute name="CacheName">jboss.cache:service=TreeCache</attribute>-->





    Referenced by: