We are using TreeCache as a placeholder in our application; we also have made this TreeCache as cluster aware. Following is the Jboss Cache configuration file | <?xml version="1.0" encoding="UTF-8"?> | | <!-- ===================================================================== --> | <!-- --> | <!-- Sample TreeCache Service Configuration --> | <!-- --> | <!-- ===================================================================== --> | | <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 | --> | <attribute name="TransactionManagerLookupClass">org.jboss.cache.GenericTransactionManagerLookup</attribute> | | <!-- | 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 | --> | <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">SampleCluster</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="localhost" start_port="7800" loopback="true"/> | <TCPPING initial_hosts="localhost[7800]" port_range="3" 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="true" down_thread="true" up_thread="true"/> | <pbcast.STATE_TRANSFER up_thread="true" down_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">true</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">15000</attribute> | | <!-- | Number of milliseconds to wait until all responses for a | synchronous call have been received. | --> | <attribute name="SyncReplTimeout">15000</attribute> | | <!-- Max number of milliseconds to wait for a lock acquisition --> | <attribute name="LockAcquisitionTimeout">10000</attribute> | | <!-- Name of the eviction policy class. --> | <attribute name="EvictionPolicyClass"></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> | | | <!-- Uncomment to get a graphical view of the TreeCache MBean above --> | <!-- <mbean code="org.jboss.cache.TreeCacheView" name="jboss.cache:service=TreeCacheView">--> | <!-- <depends>jboss.cache:service=TreeCache</depends>--> | <!-- <attribute name="CacheService">jboss.cache:service=TreeCache</attribute>--> | <!-- </mbean>--> | | | </server> | When we profiled out application specific call, using profiler. We noticed a call in Jgroups object was running for 314 times in the given 15min (Total time in which the application call was tested). This 314 call took totally 6min of the total 15min, which is takes around 40% of the total time. Following is the method flow that we got in the profiler | java.net.Socket.connect | -org.jgroups.blocks.ConnectionTable.getConnection | -org.jgroups.blocks.ConnectionTable.send | -org.jgroups.protocols.TCP.sendUnicastMessage | -org.jgroups.protocols.TCP.down | -org.jgroups.stack.DownHandler.run | The call to the Jgroups related classes never originated from our application code. We are not very sure from where this call are happening and how to stop them. Kindly let me know what might be the cause of the issue. We suspect that JbossCache using Jgroups internally and which is making this, calls. If this is not the right forum to report this issue, kindly direct me to the right place. View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3993814#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...