Replication problems with TreeCacheAOP in a Jboss Cluster

[jaywant.bhosale]

Hi,

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.

Questions:
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 -->
<!-- ==================================================================== -->



jboss:service=Naming
jboss:service=TransactionManager

<!-- Configure the TransactionManager -->
org.jboss.cache.JBossTransactionManagerLookup

<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ

<!--
Valid modes are LOCAL, REPL_ASYNC and REPL_SYNC
-->
REPL_SYNC

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

<!-- 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="192.168.0.2"
-->
<!-- 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="230.1.2.70" 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"
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"/>



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

[ben.wang]

No, once you it via putObject, any pojo operation should trigger replication.

1. Try out the tutorial example first to make sure it works.

2. Turn on the trace logging on cache to make sure there is replication. I guess is there is not. So what does your pojo operation looks like? Are they all been properly insturmented?

-Ben