6:27 a.m.
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...