Is tomcat clustering only way for session replication?

Question

I tested Tomcat Clustering for session replication on ubuntu servers with apache as front end load balancers. From my testing experience I say it's better not using tomcat clustering but running each node as standalone not knowing one another without any session replication as I felt it's slow, takes much time to startup tomcat service and consumes more memory. And the FarmDeployer is not reliable always in deploying and whole configuration should be placed under<Host></Host> element for farm deployer to work and also for each virtual hosting and thus a huge server.xml file. Below is the tomcat virtual hosting with cluster configuration from one of the node I used.

<Host name="site1.mydomain.net" debug="0" appBase="webapps" unpackWARs="true" autoDeploy="true">
<Logger className="org.apache.catalina.logger.FileLogger"
directory="logs" prefix="virtual_log1." suffix=".log" timestamp="true"/>
<Context path="" docBase="/usr/share/tomcat/webapps/myapp" debug="0" reloadable="true"/>

<Cluster className="org.apache.catalina.ha.tcp.SimpleTcpCluster">
<Manager className="org.apache.catalina.ha.session.DeltaManager" 
          expireSessionsOnShutdown="false"
          notifyListenersOnReplication="true"/>

        <Channel className="org.apache.catalina.tribes.group.GroupChannel">
            <Receiver className="org.apache.catalina.tribes.transport.nio.NioReceiver"
                  address="192.168.1.8"
                  port="4001"
                  selectorTimeout="100"
                  maxThreads="6"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/>
            <Interceptor className="org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor">
                <Member className="org.apache.catalina.tribes.membership.StaticMember"
                      port="4002"
                      securePort="-1"
                      host="192.168.1.9"
                      domain="staging-cluster"
                      uniqueId="{0,1,2,3,4,5,6,7,8,9}"/>

             <!--   <Member className="org.apache.catalina.tribes.membership.StaticMember"
                      port="4002"
                      securePort="-1"
                      host="192.168.1.9"
                      domain="staging-cluster"
                      uniqueId="{0,1,2,3,4,5,6,7,8,9}"/> -->

            </Interceptor>
        </Channel>
<Valve className="org.apache.catalina.ha.tcp.ReplicationValve" filter=""/>
<Valve className="org.apache.catalina.ha.session.JvmRouteBinderValve"/>

<ClusterListener className="org.apache.catalina.ha.session.JvmRouteSessionIDBinderListener"/>
<ClusterListener className="org.apache.catalina.ha.session.ClusterSessionListener"/>

  <Deployer className="org.apache.catalina.ha.deploy.FarmWarDeployer"
            tempDir="/usr/share/tomcat/temp/"
            deployDir="/usr/share/tomcat/webapps/"
            watchDir="/usr/share/tomcat/watch/"
            watchEnabled="true"/>
    </Cluster>
</Host>

Is Tomcat clustering good to use on production or is there any alternate way for session replication?. Or I'm missing anything in the above configuration which could be fine tuned?

Any ideas are welcome. Thanks!

Answer 1

One session-failover / session-replication solution for tomcat is memcached-session-manager (msm), supporting both sticky and non-sticky sessions. msm uses memcached (or any backend speaking the memcached protocol) as backend for session backup/storage.

In sticky mode sessions are still kept in tomcat, and memcached is only used as an additional backup - for session failover.

In non-sticky mode sessions are only stored in memcached and no longer in tomcat, as with non-sticky sessions the session-store must be external (to avoid stale data).

There's also special support for membase / membase buckets, which is useful for hosted solutions where you get access to a certain bucket with the appropriate authentication.

Session serialization is pluggable, so you're not tied to java serialization (and classes implementing Serializable). E.g. there's a kryo serializer available, which is one of the fastest serialization strategies available.

The msm home page mainly describes the sticky session approach, for details regarding non-sticky sessions you might search or ask on the mailing list.

Details and examples regarding the configuration can be found in the msm wiki (SetupAndConfiguration).