1 Reply Latest reply on Apr 10, 2007 6:30 PM by brian.stansberry

    HTTP Session Replication - immediate eviction

    lava_surfer

      I am prototyping HTTP session replication for fail over in a 2 node cluster. JBoss AS version 4.0.3SP1, JBoss Cache version 1.4.0.SP1, JGroups default as per AS, JDK 1.5.0_08.

      I have a simple two node cluster and a simple web application that writes a java.util.Date to the session each time the user clicks a submit button. The cluster appears to be working properly. Both nodes are present as verified via jmx-console in looking at the jboss service=My-Test-Partition-Tomcat and jboss.cache service=TomcatClusteringCache.

      I have a jmx-console open on each node and observe the contents of the cache via the TomcatClusteringCache MBean printDetails() method.

      I have enabled jboss cache DEBUG in log4j.xml.

      Here's what happens in my test case:

      1) Hit submit
      2) Both nodes 1 and 2 store the updated session data as seen via jmx.
      3) A second or two later, node 2 evicts the session data.
      4) Node 1 retains the session data as per the configured eviction policy.

      Perhaps I don't understand how the cache is supposed to work, but I am under the impression that each node would receive a copy of the session data as per the clustering configuration.

      Thanks in advance for your help.


      My tc5-cluster-service.xml is shown below.

      
      <?xml version="1.0" encoding="UTF-8"?>
      
      <!-- ===================================================================== -->
      <!-- -->
      <!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
      <!-- -->
      <!-- ===================================================================== -->
      
      <server>
      
       <!-- ==================================================================== -->
       <!-- Defines TreeCache configuration -->
       <!-- ==================================================================== -->
      
       <mbean code="org.jboss.cache.TreeCache"
       name="jboss.cache:service=TomcatClusteringCache">
      
       <depends>jboss:service=Naming</depends>
       <depends>jboss:service=TransactionManager</depends>
      
       <!-- Configure the TransactionManager -->
       <attribute name="TransactionManagerLookupClass">org.jboss.cache.JBossTransactionManagerLookup</attribute>
      
       <!--
       Node locking scheme:
       OPTIMISTIC
       PESSIMISTIC (default)
       -->
       <attribute name="NodeLockingScheme">OPTIMISTIC</attribute>
      
       <!--
       Isolation level : SERIALIZABLE
       REPEATABLE_READ (default)
       READ_COMMITTED
       READ_UNCOMMITTED
       NONE
       -->
       <attribute name="IsolationLevel">REPEATABLE_READ</attribute>
      
       <!--
       Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
       -->
       <attribute name="CacheMode">REPL_ASYNC</attribute>
      
       <!-- Name of cluster. Needs to be the same for all clusters, in order
       to find each other
       -->
       <attribute name="ClusterName">${jboss.partition.name:DefaultPartition}-Tomcat</attribute>
      
      
       <!-- JGroups protocol stack properties. Can also be a URL,
       e.g. file:/home/bela/default.xml
       <attribute name="ClusterProperties"></attribute>
       -->
      
       <attribute name="ClusterConfig">
       <!--
       The default UDP stack:
       - If you have a multihomed machine, set the UDP protocol's bind_addr attribute to the
       appropriate NIC IP address, e.g bind_addr="192.168.0.2".
       - On Windows machines, because of the media sense feature being broken with multicast
       (even after disabling media sense) set the UDP protocol's loopback attribute to true
       -->
       <config>
       <UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" mcast_port="48866"
       ip_ttl="64" ip_mcast="true"
       mcast_send_buf_size="150000" mcast_recv_buf_size="80000"
       ucast_send_buf_size="150000" ucast_recv_buf_size="80000"
       loopback="false"/>
       <PING timeout="2000" num_initial_members="3"
       up_thread="false" down_thread="false"/>
       <MERGE2 min_interval="10000" max_interval="20000"/>
       <FD_SOCK/>
       <VERIFY_SUSPECT timeout="1500"
       up_thread="false" down_thread="false"/>
       <pbcast.NAKACK gc_lag="50" retransmit_timeout="600,1200,2400,4800"
       max_xmit_size="8192" up_thread="false" down_thread="false"/>
       <UNICAST timeout="600,1200,2400" window_size="100" min_threshold="10"
       down_thread="false"/>
       <pbcast.STABLE desired_avg_gossip="20000"
       up_thread="false" down_thread="false"/>
       <FRAG frag_size="8192"
       down_thread="false" up_thread="false"/>
       <pbcast.GMS join_timeout="5000" join_retry_timeout="2000"
       shun="true" print_local_addr="true"/>
       <pbcast.STATE_TRANSFER up_thread="true" down_thread="true"/>
       </config>
      
       </attribute>
      
       <!-- Max number of milliseconds to wait for a lock acquisition -->
       <attribute name="LockAcquisitionTimeout">15000</attribute>
      
      
       <attribute name="EvictionPolicyClass">org.jboss.cache.eviction.LRUPolicy</attribute>
      
       <attribute name="EvictionPolicyConfig">
       <config>
       <attribute name="wakeUpIntervalSeconds">30</attribute>
       <region name="/_default_">
       <attribute name="maxNodes">10000</attribute>
       <attribute name="timeToLiveSeconds">1800</attribute>
       <attribute name="maxAgeSeconds">1800</attribute>
       </region>
       </config>
       </attribute>
      
       </mbean>
      </server>