[jboss-user] [Clustering] - JBoss Cache Replication not happening in a clustered environ
ramesh-smx
do-not-reply at jboss.com
Tue Sep 29 14:03:21 EDT 2009
Hi,
We have couple of JBoss nodes set up in a clustered mode and we are testing whether the JBoss cache is getting replicated properly. The nodes are coming up properly and joining the cluster as far as we can verify. The only problem is that changes to the cache is not getting replicated between the nodes. I have attached the configuration we are using below.
Is there any way to debug the cache replication issue? Any logs that we can look at? Since we are setting this up for the first time, any help would be appreciated.
Thanks,
Ramesh
----------------------------------------------
<jbosscache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="urn:jboss:jbosscache-core:config:3.0">
<!--
isolation levels supported: READ_COMMITTED and REPEATABLE_READ
nodeLockingSchemes: mvcc, pessimistic (deprecated), optimistic (deprecated)
-->
<!--
Used to register JMX statistics in any available MBean server
-->
<!--
If region based marshalling is used, defines whether new regions are inactive on startup.
-->
<!--
Used to register JVM shutdown hooks.
hookBehavior: DEFAULT, REGISTER, DONT_REGISTER
-->
<!--
Used to define async listener notification thread pool size
-->
<!--
Used to enable invocation batching and allow the use of Cache.startBatch()/endBatch() methods.
-->
<!--
serialization related configuration, used for replication and cache loading
-->
<!-- cluster configuration -->
<!--
Defines whether to retrieve state on startup
-->
<!--
Network calls are synchronous.
-->
<!-- -->
<!--
Uncomment this for async replication.
-->
<!-- Uncomment to use Buddy Replication -->
<!--
numBuddies = 1
ignoreColocatedBuddies = true
-->
<!--
Configures the JGroups channel. Looks up a JGroups config file on the classpath or filesystem. udp.xml
ships with jgroups.jar and will be picked up by the class loader.
-->
<!-- -->
<!-- uncomment to define a JGroups stack here-->
<UDP bind_addr="10.10.1.245"
mcast_send_buf_size="32000"
mcast_port="45566"
ucast_recv_buf_size="64000"
loopback="true"
mcast_recv_buf_size="64000"
max_bundle_size="30000"
max_bundle_timeout="30"
use_incoming_packet_handler="false"
use_outgoing_packet_handler="false"
ucast_send_buf_size="32000"
ip_ttl="32"
enable_bundling="true"/>
<PING timeout="2000" num_initial_members="3"/>
<MERGE2 max_interval="30000" min_interval="10000"/>
<FD_SOCK/>
<FD timeout="10000" max_tries="5" shun="true"/>
<VERIFY_SUSPECT timeout="1500"/>
<pbcast.NAKACK use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="5000" shun="false"
view_bundling="true" view_ack_collection_timeout="5000"/>
<FRAG2 frag_size="60000"/>
<pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>
<pbcast.FLUSH timeout="0"/>
<!-- Alternate TCP stack: customize it for your environment, change bind_addr and initial_hosts -->
<!-- <TCP bind_addr="10.10.1.245" start_port="7800" loopback="true"
tcp_nodelay="true"
recv_buf_size="20000000"
send_buf_size="640000"
discard_incompatible_packets="true"
enable_bundling="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
use_send_queues="false"
sock_conn_timeout="300"
skip_suspected_members="true"/>
<TCPPING initial_hosts="10.10.1.245[7800], 10.10.1.245[7800]" port_range="3"
timeout="3000"
num_initial_members="3"/>
<MERGE2 max_interval="100000"
min_interval="20000"/>
<FD_SOCK />
<FD timeout="10000" max_tries="5" shun="true"/>
<VERIFY_SUSPECT timeout="1500" />
<pbcast.NAKACK use_mcast_xmit="false" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
discard_delivered_msgs="true"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="400000"/>
<pbcast.GMS print_local_addr="true" join_timeout="3000" shun="true"
view_bundling="true"/>
<pbcast.STATE_TRANSFER /> -->
<!--
Eviction configuration. WakeupInterval defines how often the eviction thread runs, in milliseconds.
0 means the eviction thread will never run.
-->
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257720#4257720
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4257720
More information about the jboss-user
mailing list