[jboss-cvs] JBossAS SVN: r99331 - projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Wed Jan 13 02:50:49 EST 2010
Author: laubai
Date: 2010-01-13 02:50:49 -0500 (Wed, 13 Jan 2010)
New Revision: 99331
Modified:
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
Log:
Partial correction to JBoss Cache JGroups chapter.
Modified: projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-13 06:12:58 UTC (rev 99330)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-13 07:50:49 UTC (rev 99331)
@@ -496,57 +496,88 @@
</varlistentry>
</variablelist>
</section>
- <!--hajime-->
+
<section id="jbosscache-jgroups-transport-tunnel">
<title>TUNNEL configuration</title>
- <para>The TUNNEL protocol uses an external router to send messages. The external router is known as
- a <literal>GossipRouter</literal>. Each node has to register with the router. All messages are sent to the router and forwarded on to their destinations. The TUNNEL approach can be used to setup communication with nodes behind firewalls. A node can establish a TCP connection to the GossipRouter through the firewall (you can use port 80). The same connection is used by the router to send messages to nodes behind the firewall as most firewalls do not permit outside hosts to initiate a TCP connection to a host inside the firewall. The TUNNEL configuration is defined in the TUNNEL element in the JGroups Config element. Here is an example..
- </para>
-
+ <para>
+ The TUNNEL protocol uses an external router known as the <classname>GossipRouter</classname>
+ to send messages. Each node must register with this router. All messages are sent to the
+ router and forwarded to their destinations. The TUNNEL approach can be used to set up
+ communication with nodes behind firewalls. A node can establish a TCP connection to the
+ <classname>GossipRouter</classname> through the firewall via port 80. This connection is
+ also used by the router to send messages to nodes behind the firewall, since most firewalls
+ do not permit outside hosts to initiate a TCP connection to a host inside the firewall.
+ The TUNNEL configuration is defined in the <literal>TUNNEL</literal> sub-element in the
+ JGroups <literal>Config</literal> element, like so:
+ </para>
- <programlisting>
-<TUNNEL router_port="12001"
+ <programlisting><![CDATA[
+<TUNNEL router_port="12001"
router_host="192.168.5.1"
- down_thread="false" up_thread="false/>
- </programlisting>
+ down_thread="false" up_thread="false/>
+]]> </programlisting>
-<para>The available attributes in the <literal>TUNNEL</literal> element are listed below.</para>
- <itemizedlist>
- <listitem>
- <para><emphasis role="bold">router_host</emphasis> specifies the host on which the
- GossipRouter is running.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">router_port</emphasis> specifies the port on which the
- GossipRouter is listening.</para>
- </listitem>
- <listitem>
- <para><emphasis role="bold">loopback</emphasis> specifies whether to loop messages back up
- the stack. The default is <literal>true</literal>.</para>
- </listitem>
- </itemizedlist>
+<para>The attributes available to the <literal>TUNNEL</literal> element are listed below.</para>
+<variablelist>
+ <varlistentry>
+ <term><varname>router_host</varname></term>
+ <listitem>
+ <para>
+ Specifies the host on which the <classname>GossipRouter</classname> runs.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>router_port</varname></term>
+ <listitem>
+ <para>
+ Specifies the port on which the <classname>GossipRouter</classname> listens.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>loopback</varname></term>
+ <listitem>
+ <para>
+ Specifies whether to loop messages back up the stack. The default value is
+ <literal>true</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+</variablelist>
+
</section>
</section>
-
-
<section id="jbosscache-jgroups-discovery">
<title>Discovery Protocols</title>
<para>
- The cluster needs to maintain a list of current member nodes at all times so that the load balancer and client interceptor know how to route their requests. Discovery protocols are used to discover active nodes in the cluster and detect the oldest member of the cluster, which is the coordinator. All initial nodes are discovered when the cluster starts up.
- When a new node joins the cluster later, it is only discovered after the group membership protocol
- (GMS, see <xref linkend="jbosscache-jgroups-other-gms"/>) admits it into the group.</para>
- <para>Since the discovery protocols sit on top of the transport protocol, you can choose to use different discovery protocols based on your transport protocol. These are also configured as sub-elements in the JGroups MBean <literal>Config</literal> element.</para>
+ The cluster needs to maintain a list of current member nodes at all times so that the
+ load balancer and client interceptor know how to route their requests. Discovery protocols
+ are used to discover active nodes in the cluster and detect the oldest member of the cluster,
+ which is the coordinator. All initial nodes are discovered when the cluster starts up.
+ When a new node joins the cluster later, it is only discovered after the group membership
+ protocol (GMS, see <xref linkend="jbosscache-jgroups-other-gms"/>) admits it into the group.
+ </para>
+ <para>
+ Since the discovery protocols sit on top of the transport protocol, you can choose to use
+ different discovery protocols based on your transport protocol. These are also configured as
+ sub-elements in the JGroups MBean <literal>Config</literal> element.
+ </para>
+ <!--hajime-->
-
<section id="jbosscache-jgroups-discovery-ping">
<title>PING</title>
<para>
- PING is a discovery protocol that works by either multicasting PING requests to an IP multicast address or connecting to a gossip router. As such, PING normally sits on top of the UDP or TUNNEL transport protocols. Each node responds with a packet {C, A}, where C=coordinator's address and A=own address. After timeout milliseconds or num_initial_members replies, the joiner determines the coordinator from the responses, and sends a JOIN request to it (handled by). If nobody responds, we assume we are the first member of a group.
+ PING is a discovery protocol that works by either multicasting PING requests to an IP
+ multicast address or connecting to a gossip router. As such, PING normally sits on top of
+ the UDP or TUNNEL transport protocols. Each node responds with a packet
+ <literal>{C, A}</literal>, where <literal>C</literal> is the coordinator's address, and
+ <literal>=coordinator's address and A=own address. After timeout milliseconds or num_initial_members replies, the joiner determines the coordinator from the responses, and sends a JOIN request to it (handled by). If nobody responds, we assume we are the first member of a group.
</para>
<para>Here is an example PING configuration for IP multicast.
</para>
More information about the jboss-cvs-commits
mailing list