Yes I was very confused and was configuring the TreeCache in one deployment descriptor (syncRepl.xml) and the TreeCacheAop in another (jboss-service.xml), since I assumed this was how things worked based on the various documents I've found on this topic (these documents don't seem to be synchronized or complete, my only excuse for making this bonehead mistake). It seemed weird to me at the time but it was sort of working so I thought maybe it was correct, just with the wrong attribute values. Thanks for making your observation which has prompted me to configure the TreeCacheAop MBean in the jboss-service.xml that I include in my SAR.
Unfortunately having the TreeCacheAop configuration in the right file still doesn't solve my problem, in that replication just isn't happening across the two nodes of my cluster. I currently have the following as my TreeCacheAop MBean entry in my SAR's jboss-service.xml: | <mbean code="org.jboss.cache.aop.TreeCacheAop" | name="jboss.cache:service=TreeCacheAop"> | <attribute name="CacheMode">REPL_SYNC</attribute> | <attribute name="ClusterName">TreeCache-Cluster</attribute> | <attribute name="ClusterConfig"> | <config> | <UDP mcast_addr="228.1.2.39" | mcast_port="45566" | ip_ttl="64" | ip_mcast="true" | bind_addr="localhost" | 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" | up_thread="false" | down_thread="false"/> | <pbcast.STABLE desired_avg_gossip="20000" | up_thread="false" | down_thread="false"/> | <UNICAST timeout="600,1200,2400" | window_size="100" | min_threshold="10" | 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> | </mbean> | (I don't have the TransactionManagerLookupClass entry because I get exceptions with both DummyTransactionManagerLookup and TransactionManagerLookup, but I'm assuming that's unrelated to the current woes and is something to be addressed later.) In server.log I see the following messages which indicate that the TreeCacheAop is being started fine but that it isn't communicating with any other TreeCacheAop in its TreeCache-Cluster, which explains why there is no replication (this is the server.log from the second node, started about 5 minutes after the first node of the cluster, and after there are already data stored in the TreeCacheAop on the first node): | 2005-03-07 15:12:22,033 INFO [org.jboss.cache.aop.TreeCacheAop] interceptor chain is: | class org.jboss.cache.interceptors.CallInterceptor | class org.jboss.cache.interceptors.LockInterceptor | class org.jboss.cache.interceptors.CreateIfNotExistsInterceptor | class org.jboss.cache.interceptors.ReplicationInterceptor | | 2005-03-07 15:12:22,033 INFO [org.jboss.cache.aop.TreeCacheAop] cache mode is REPL_SYNC | | 2005-03-07 15:12:22,054 INFO [STDOUT] | ------------------------------------------------------- | GMS: address is localhost:37159 | ------------------------------------------------------- | | 2005-03-07 15:12:24,065 INFO [org.jboss.cache.aop.TreeCacheAop] | viewAccepted(): new members: [localhost:37159] | | 2005-03-07 15:12:24,066 INFO [org.jboss.cache.aop.TreeCacheAop] | state could not be retrieved (must be first member in group) | | 2005-03-07 15:12:24,066 DEBUG [org.jboss.cache.aop.TreeCacheAop] | Started jboss.cache:service=TreeCacheAop | | Something else of interest is that when I remove the ClusterConfig attribute from the TreeCacheAop MBean entry I get the following messages instead which show that there is communication between the two TreeCacheAop MBeans, and the current state of the TreeCacheAop on the first node is actually fetched to the newly started TreeCacheAop on the second node, although the replication ends there: | 2005-03-07 17:16:20,299 INFO [org.jboss.cache.aop.TreeCacheAop] | cache mode is REPL_SYNC | | 2005-03-07 17:16:20,300 DEBUG [org.jboss.cache.aop.TreeCacheAop] | setting cluster properties to default value | | 2005-03-07 17:16:20,323 INFO [STDOUT] | ------------------------------------------------------- | GMS: address is canal:37219 | ------------------------------------------------------- | | 2005-03-07 17:16:22,340 INFO [org.jboss.cache.aop.TreeCacheAop] | viewAccepted(): new members: [brooklyn:32989, canal:37219] | | 2005-03-07 17:16:22,353 INFO [org.jboss.cache.aop.TreeCacheAop] | received the state (size=818 bytes) | | 2005-03-07 17:16:22,353 INFO [org.jboss.cache.aop.TreeCacheAop] | transient state: 766 bytes | | 2005-03-07 17:16:22,353 INFO [org.jboss.cache.aop.TreeCacheAop] | setting transient state | | 2005-03-07 17:16:22,354 DEBUG [org.jboss.cache.lock.IdentityLock] | Cache instance is null. Use default lock strategy | | 2005-03-07 17:16:22,354 DEBUG [org.jboss.cache.lock.IdentityLock] | Cache instance is null. Use default lock strategy | | 2005-03-07 17:16:22,355 DEBUG [org.jboss.cache.lock.IdentityLock] | Cache instance is null. Use default lock strategy | | 2005-03-07 17:16:22,364 INFO [org.jboss.cache.aop.TreeCacheAop] | locking the old tree | | 2005-03-07 17:16:22,364 INFO [org.jboss.cache.aop.TreeCacheAop] | locking the old tree was successful | | 2005-03-07 17:16:22,364 INFO [org.jboss.cache.aop.TreeCacheAop] | setting the transient state was successful | | 2005-03-07 17:16:22,365 INFO [org.jboss.cache.aop.TreeCacheAop] | forcing release of all locks in old tree | | 2005-03-07 17:16:22,365 INFO [org.jboss.cache.aop.TreeCacheAop] | state was retrieved successfully (in 25 milliseconds | | 2005-03-07 17:16:22,366 DEBUG [org.jboss.cache.aop.TreeCacheAop] | Started jboss.cache:service=TreeCacheAop | Notice above that when the ClusterConfig is left out then the actual name of the server, canal, is listed in the GMS info message, whereas before it was listed as localhost. Does this tell us anything ? Thanks for any more advice or suggestions. --James View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=3869129#3869129 Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=3869129 ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ JBoss-Development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jboss-development
