1 Reply Latest reply on Aug 18, 2008 7:26 AM by Mircea Markus

    Using TCP to do clustering

    Tarik Singh Newbie

      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