Failing to connect a treecache using TCP
bentemperton Apr 26, 2007 4:56 AMI have two machines (FIRST_BOX and SECOND_BOX)running applications using hibernate 3.2.2 to talk to an oracle 10g database, using JBossCache 1.4.1SP3 as the secondary level cache.
FIRST_BOX is always started first.
My treecache.xml file looks like this:
<server> <classpath codebase="./lib" archives="jboss-cache.jar, jgroups.jar"/> <!-- ==================================================================== --> <!-- Defines TreeCache configuration --> <!-- ==================================================================== --> <mbean code="org.jboss.cache.TreeCache" name="jboss.cache:service=TreeCache"> <depends>jboss:service=Naming</depends> <depends>jboss:service=TransactionManager</depends> <!-- Configure the TransactionManager : no matter since Hibernate will plug in an "adapter" to its own TransactionManagerLookup strategy here --> <attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute> <!-- Node locking scheme: OPTIMISTIC PESSIMISTIC (default) --> <attribute name="NodeLockingScheme">OPTIMISTIC</attribute> <!-- Note that this attribute is IGNORED if your NodeLockingScheme above is OPTIMISTIC. Isolation level : SERIALIZABLE REPEATABLE_READ (default) READ_COMMITTED READ_UNCOMMITTED NONE --> <attribute name="IsolationLevel">REPEATABLE_READ</attribute> <!-- Valid modes are LOCAL REPL_ASYNC REPL_SYNC INVALIDATION_ASYNC INVALIDATION_SYNC INVALIDATION_ASYNC is highly recommended as the mode for use with clustered second-level caches. --> <attribute name="CacheMode">REPL_ASYNC</attribute> <!-- Just used for async repl: use a replication queue --> <attribute name="UseReplQueue">false</attribute> <!-- Replication interval for replication queue (in ms) --> <attribute name="ReplQueueInterval">0</attribute> <!-- Max number of elements which trigger replication --> <attribute name="ReplQueueMaxElements">0</attribute> <!-- Name of cluster. Needs to be the same for all clusters, in order to find each other --> <attribute name="ClusterName">TreeCache-Cluster</attribute> <!-- JGroups protocol stack properties. Can also be a URL, e.g. file:/home/bela/default.xml <attribute name="ClusterProperties"></attribute> --> <attribute name="ClusterConfig"> <config> <TCP bind_addr="FIRST_BOX" start_port="6800" loopback="true"/> <TCPPING initial_hosts="FIRST_BOX[6800]" port_range="5" timeout="3500" num_initial_members="3" up_thread="true" down_thread="true"/> <MERGE2 min_interval="5000" max_interval="10000"/> <FD shun="true" timeout="2500" max_tries="5" up_thread="true" down_thread="true"/> <VERIFY_SUSPECT timeout="1500" down_thread="false" up_thread="false"/> <pbcast.NAKACK down_thread="true" up_thread="true" gc_lag="100" retransmit_timeout="3000"/> <pbcast.STABLE desired_avg_gossip="20000" down_thread="false" up_thread="false"/> <pbcast.GMS join_timeout="5000" join_retry_timeout="2000" shun="false" print_local_addr="false" down_thread="true" up_thread="true"/> </config> </attribute> <!-- Whether or not to fetch state on joining a cluster NOTE this used to be called FetchStateOnStartup and has been renamed to be more descriptive. --> <attribute name="FetchInMemoryState">false</attribute> <!-- Number of milliseconds to wait until all responses for a synchronous call have been received. --> <attribute name="SyncReplTimeout">20000</attribute> <!-- Max number of milliseconds to wait for a lock acquisition --> <attribute name="LockAcquisitionTimeout">15000</attribute> <!-- The max amount of time (in milliseconds) we wait until the initial state (ie. the contents of the cache) are retrieved from existing members in a clustered environment --> <attribute name="InitialStateRetrievalTimeout">20000</attribute> <!-- Indicate whether to use marshalling or not. Set this to true if you are running under a scoped class loader, e.g., inside an application server. Default is "false". --> <attribute name="UseMarshalling">false</attribute> </mbean> </server>
FIRST_BOX starts up fine, sets up the cache without errors etc. When SECOND_BOX starts up, it throws an exception stating that it cannot create a TreeCache-Cluster, because the cluster already exists:
[java] main 09:54:15,934 ERROR TreeCache:283 - Starting failed jboss.cache:service=TreeCache-Cluster [java] javax.management.InstanceAlreadyExistsException: jboss.cache:service=TreeCache-Cluster [java] at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerIntercepto r.java:1484) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerDynamicMBean(DefaultMBeanServerIntercep tor.java:963) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerObject(DefaultMBeanServerInterceptor.ja va:917) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.jav a:312) [java] at com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:482) [java] at org.jboss.cache.util.MBeanConfigurator.registerInterceptors(MBeanConfigurator.java:67) [java] at org.jboss.cache.TreeCache._createService(TreeCache.java:1241) [java] at org.jboss.cache.TreeCache.startService(TreeCache.java:1306) [java] at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:271) [java] at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:172) [java] at org.hibernate.cache.OptimisticTreeCacheProvider.start(OptimisticTreeCacheProvider.java:94) [java] at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:183) [java] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294) [java] at com.qxlva.mm.dispensing.loadtest.client.PreloadKeystoresTask.<clinit>(PreloadKeystoresTask.java:54) [java] at com.qxlva.mm.dispensing.loadtest.client.PharmacyClient.preloadKeyStores(PharmacyClient.java:168) [java] at com.qxlva.mm.dispensing.loadtest.client.PharmacyClient.main(PharmacyClient.java:87) [java] Exception in thread "main" java.lang.ExceptionInInitializerError [java] at com.qxlva.mm.dispensing.loadtest.client.PreloadKeystoresTask.<clinit>(PreloadKeystoresTask.java:59) [java] at com.qxlva.mm.dispensing.loadtest.client.PharmacyClient.preloadKeyStores(PharmacyClient.java:168) [java] at com.qxlva.mm.dispensing.loadtest.client.PharmacyClient.main(PharmacyClient.java:87) [java] Caused by: org.hibernate.cache.CacheException: javax.management.InstanceAlreadyExistsException: jboss.cache: service=TreeCache-Cluster [java] at org.hibernate.cache.OptimisticTreeCacheProvider.start(OptimisticTreeCacheProvider.java:97) [java] at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:183) [java] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294) [java] at com.qxlva.mm.dispensing.loadtest.client.PreloadKeystoresTask.<clinit>(PreloadKeystoresTask.java:54) [java] ... 2 more [java] Caused by: javax.management.InstanceAlreadyExistsException: jboss.cache:service=TreeCache-Cluster [java] at com.sun.jmx.mbeanserver.Repository.addMBean(Repository.java:453) [java] at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.internal_addObject(DefaultMBeanServerIntercepto r.java:1484) [java] main 09:54:15,934 FATAL PreloadKeystoresTask:58 - Error creating dedicated session factory [java] org.hibernate.cache.CacheException: javax.management.InstanceAlreadyExistsException: jboss.cache:service=Tre eCache-Cluster
If I comment out the name of the ClusterName on the second box, the first box starts rejecting messages when the second box starts up, saying that the messages are from a different group "TreeCache-Group". I was under the impression from the comments in the treecache.xml that the ClusterName had to be the same in each node for them to find each other.
Can you please tell me where I've gone wrong?
Cheers,
Ben