1 Reply Latest reply on Aug 23, 2005 8:07 PM by ben.wang

    Replication problems with TreeCacheAOP in a Jboss Cluster

    Jaywant Bhosale Newbie


      Here is my problem:

      - I am running a Web application in a JBOSS Cluster
      - Using TreeCacheAOP to store the user state information in a POJO
      - apache Mod_jk to load balance requests (Round Robin mechanism)

      Case1: WORKS
      Request goes to on Node 1: Request stores the POJO calling putObject()
      Request goes to on Node 2: The object is replicated and found

      Case2: WORKS
      Request goes to on Node 1: Request get's the POJO calling getObject() and modifies it and calls putObject() again.
      Request goes to on Node 2: The object is REPLICATED on both nodes

      Case3: DOES NOT WORK
      Request goes to on Node 1: Request get's the POJO calling getObject() and modifies it (Does not call putObject() again this time).
      Request goes to on Node 2: The object is NOT REPLICATED , but on Node1 The changes exist , so in this case the treecache on the two nodes have different values.

      1. Is replication triggered only on calling putObject() can we not get the Object from TreeCacheAOP and make changes without having to put it back again (In my case the changes are made at different levels and I need the cache replicated after every change). I am NOT using transactions.

      My Settings are as follows:

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

      <!-- ===================================================================== -->
      <!-- -->
      <!-- Customized TreeCache Service Configuration for Tomcat 5 Clustering -->
      <!-- -->
      <!-- ===================================================================== -->

      <!-- ==================================================================== -->
      <!-- Defines TreeCache configuration -->
      <!-- ==================================================================== -->


      <!-- Configure the TransactionManager -->

      Isolation level : SERIALIZABLE
      REPEATABLE_READ (default)

      Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC

      <!-- Name of cluster. Needs to be the same for all clusters, in order
      to find each other

      <!-- JGroups protocol stack properties. Can also be a URL,
      e.g. file:/home/bela/default.xml


      <!-- UDP: if you have a multihomed machine,
      set the bind_addr attribute to the appropriate NIC IP address, e.g bind_addr=""
      <!-- UDP: On Windows machines, because of the media sense feature
      being broken with multicast (even after disabling media sense)
      set the loopback attribute to true -->
      <UDP mcast_addr="" mcast_port="45577"
      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"
      <PING timeout="2000" num_initial_members="3"
      up_thread="false" down_thread="false"/>
      <MERGE2 min_interval="10000" max_interval="20000"/>
      <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"
      <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"/>

      <!-- Max number of milliseconds to wait for a lock acquisition -->