Using TCP to do clustering
Hi,
I am using TCP to setup a jboss cache cluster. I have modified the demo-cache-config.xml in jbosscache-demo-1.0.BETA1 to detect the other jboss caches. For this I specified the address of my both the machines in mcast_addr to 10.1.200.129, which is the IP of one of my machines. When I launched the demo on both the applications they could not detect each other. The view in the control panel also shows the UDP version of the xml.
I cannot use the UDP protocol.
Please find attached the config xml.
<?xml version="1.0" encoding="UTF-8"?>
<!-- ===================================================================== -->
<!-- -->
<!-- Sample TreeCache Service Configuration -->
<!-- -->
<!-- ===================================================================== -->
<!-- ==================================================================== -->
<!-- Defines TreeCache configuration -->
<!-- ==================================================================== -->
jboss:service=Naming
jboss:service=TransactionManager
<!--
Configure the TransactionManager
-->
org.jboss.cache.transaction.GenericTransactionManagerLookup
<!--
Isolation level : SERIALIZABLE
REPEATABLE_READ (default)
READ_COMMITTED
READ_UNCOMMITTED
NONE
-->
REPEATABLE_READ
<!--
Valid modes are LOCAL
REPL_ASYNC
REPL_SYNC
INVALIDATION_ASYNC
INVALIDATION_SYNC
-->
REPL_SYNC
<!--
Just used for async repl: use a replication queue
-->
false
<!--
Replication interval for replication queue (in ms)
-->
0
<!--
Max number of elements which trigger replication
-->
0
<!-- Name of cluster. Needs to be the same for all TreeCache nodes in a
cluster in order to find each other.
-->
JBossCache-Cluster
<!--Uncomment next three statements to enable JGroups multiplexer.
This configuration is dependent on the JGroups multiplexer being
registered in an MBean server such as JBossAS. -->
jgroups.mux:name=Multiplexer
jgroups.mux:name=Multiplexer
fc-fast-minimalthreads
<!-- JGroups protocol stack properties.
ClusterConfig isn't used if the multiplexer is enabled and successfully initialized.
-->
<TCP recv_buf_size="20000000" use_send_queues="false"
loopback="false"
discard_incompatible_packets="true"
max_bundle_size="64000"
max_bundle_timeout="30"
use_incoming_packet_handler="true"
enable_bundling="true"
enable_unicast_bundling="true"
enable_diagnostics="true"
use_concurrent_stack="true"
thread_naming_pattern="pl"
thread_pool.enabled="true"
thread_pool.min_threads="1"
thread_pool.max_threads="4"
thread_pool.keep_alive_time="30000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="50000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="2"
oob_thread_pool.max_threads="4"
oob_thread_pool.keep_alive_time="10000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="10"
oob_thread_pool.rejection_policy="Run"/>
<!--<PING timeout="2000" num_initial_members="3"/>-->
<MPING mcast_addr="10.1.200.129" 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"
join_retry_timeout="2000" shun="false"
view_bundling="true" view_ack_collection_timeout="5000"/>
<FC max_credits="5000000"
min_threshold="0.20"/>
<FRAG2 frag_size="60000"/>
<pbcast.STREAMING_STATE_TRANSFER use_reading_thread="true"/>
<!-- <pbcast.STATE_TRANSFER/> -->
<pbcast.FLUSH timeout="0"/>
<!--
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.
-->
true
<!--
The max amount of time (in milliseconds) we wait until the
state (ie. the contents of the cache) are retrieved from
existing members in a clustered environment
-->
15000
<!--
Number of milliseconds to wait until all responses for a
synchronous call have been received.
-->
15000
<!-- Max number of milliseconds to wait for a lock acquisition -->
10000
<!-- Buddy Replication config -->
true
<!-- these are the default values anyway -->
org.jboss.cache.buddyreplication.NextMemberBuddyLocator
<!-- numBuddies is the number of backup nodes each node maintains. ignoreColocatedBuddies means that
each node will *try* to select a buddy on a different physical host. If not able to do so though,
it will fall back to colocated nodes. -->
numBuddies = 10
ignoreColocatedBuddies = true
<!-- A way to specify a preferred replication group. If specified, we try and pick a buddy why shares
the same pool name (falling back to other buddies if not available). This allows the sysdmin to hint at
backup buddies are picked, so for example, nodes may be hinted topick buddies on a different physical rack
or power supply for added fault tolerance. -->
myBuddyPoolReplicationGroup
<!-- communication timeout for inter-buddy group organisation messages (such as assigning to and removing
from groups -->
2000
<!-- the following three elements, all relating to data gravitation, default to false -->
<!-- Should data gravitation be attempted whenever there is a cache miss on finding a node?
If false, data will only be gravitated if an Option is set enabling it -->
false
<!-- removes data on remote caches' trees and backup subtrees when gravitated to a new data owner -->
true
<!-- search backup subtrees as well for data when gravitating. Results in backup nodes being able to
answer data gravitation requests. -->
true
<!--
Indicate whether to use region based 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".
-->
false
<!-- Uncomment to get a graphical view of the TreeCache MBean above -->
<!-- -->
<!-- jboss.cache:service=TreeCache-->
<!-- jboss.cache:service=TreeCache-->
<!-- -->
Please suggest what am I doing worng here.
Thanks in advance
Tarik
