[jboss-cvs] JBossAS SVN: r99269 - 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
Tue Jan 12 02:42:57 EST 2010
Author: laubai
Date: 2010-01-12 02:42:57 -0500 (Tue, 12 Jan 2010)
New Revision: 99269
Modified:
projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml
Log:
Partially edited Admin&Config Clustering 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-12 07:22:44 UTC (rev 99268)
+++ projects/docs/enterprise/EWP_5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JBoss_Cache_JGroups.xml 2010-01-12 07:42:57 UTC (rev 99269)
@@ -6,19 +6,23 @@
<para>
<indexterm><primary>Clustering</primary><secondary>JBossCache and JGroups Services</secondary></indexterm>
-JGroups and JBossCache provide the underlying communication, node replication and caching services, for
- JBoss Enterprise Web Platform clusters. Those services are configured as MBeans. There is a set of JBossCache and JGroups MBeans
- for each type of clustering applications (e.g., the Stateful Session EJBs, HTTP session replication etc.).
- </para>
- <para>The JBoss Enterprise Web Platform ships with a reasonable set of default JGroups and JBossCache MBean configurations. Most
- applications just work out of the box with the default MBean configurations. You only need to tweak them
- when you are deploying an application that has special network or performance requirements.</para>
+ JGroups and JBoss Cache provide the underlying communication, node replication, and caching
+ services for clusters in JBoss Enterprise Web Platform. These services are configured as
+ <emphasis>MBeans</emphasis>. There is a set of JBoss Cache and JGroups MBeans for each type
+ of clustering application.</para>
+
+ <para>The JBoss Enterprise Web Platform ships with a reasonable set of default JGroups and
+ JBoss Cache MBean configurations. Most applications work out of the box with the default
+ MBean configurations. You only need to tweak them when you are deploying an application that
+ has special network or performance requirements.</para>
<section id="jbosscache-jgroups">
<title>JGroups Configuration</title>
- <para>The JGroups framework provides services to enable peer-to-peer communications between nodes in a
- cluster. It is built on top a stack of network communication protocols that provide transport,
- discovery, reliability and failure detection, and cluster membership management services. <xref linkend="jbosscache-JGroupsStack.fig"/> shows the protocol stack in JGroups.</para>
+ <para>The JGroups framework provides services to enable peer-to-peer communications between
+ nodes in a cluster. It is built on top a stack of network communication protocols that
+ provide transport, discovery, reliability and failure detection, and cluster membership
+ management services. <xref linkend="jbosscache-JGroupsStack.fig"/> shows the protocol stack
+ in JGroups.</para>
<figure id="jbosscache-JGroupsStack.fig">
<title>Protocol stack in JGroups</title>
<mediaobject>
@@ -27,11 +31,12 @@
</imageobject>
</mediaobject>
</figure>
- <para>JGroups configurations often appear as a nested attribute in cluster related MBean services, such as
- the <literal>PartitionConfig</literal> attribute in the <literal>ClusterPartition</literal> MBean or the
- <literal>ClusterConfig</literal> attribute in the <literal>TreeCache</literal> MBean. You can
- configure the behavior and properties of each protocol in JGroups via those MBean attributes. Below is
- an example JGroups configuration in the <literal>ClusterPartition</literal> MBean.</para>
+ <para>JGroups configurations often appear as a nested attribute in cluster related MBean
+ services, such as the <varname>PartitionConfig</varname> attribute in the
+ <classname>ClusterPartition</classname> MBean or the <varname>ClusterConfig</varname> attribute
+ in the <classname>TreeCache</classname> MBean. You can configure the behavior and properties
+ of each protocol in JGroups via those MBean attributes. Below is an example JGroups
+ configuration in the <classname>ClusterPartition</classname> MBean.</para>
<programlisting><![CDATA[
<mbean code="org.jboss.ha.framework.server.ClusterPartition"
name="jboss:service=${jboss.partition.name:DefaultPartition}">
@@ -90,28 +95,54 @@
</mbean> ]]>
</programlisting>
<para>
- All the JGroups configuration data is contained in the <Config> element under the JGroups config MBean attribute. This information is used to configure a JGroups Channel; the Channel is conceptually similar to a socket, and manages communication between peers in a cluster. Each element inside the <Config> element defines a particular JGroups Protocol; each Protocol performs one function, and the combination of those functions is what defines the characteristics of the overall Channel. In the next several sections, we will dig into the commonly used protocols and their options and explain exactly what they mean.
+ All the JGroups configuration data is contained in the <literal><![CDATA[<Config>]]></literal>
+ element under the JGroups config MBean attribute. This information is used to configure a
+ JGroups <classname>Channel</classname>. A Channel is conceptually similar to a socket, and manages
+ communication between peers in a cluster. Each element inside the
+ <literal><![CDATA[<Config>]]></literal> element defines a particular JGroups
+ <classname>Protocol</classname>; each Protocol performs one function, and the combination of
+ those functions is what defines the characteristics of the overall Channel. In the next several
+ sections, we will dig into the commonly used protocols and their options and explain exactly
+ what they mean.
</para>
</section>
<section><title>Common Configuration Properties</title>
- <para>The following common properties are exposed by all of the JGroups protocols discussed below:
+ <para>
+ The following common properties are exposed by all of the JGroups protocols discussed below:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term><varname>down_thread</varname></term>
+ <listitem>
+ <para>
+ Whether the protocol should create an internal queue and a queue processing thread
+ (also known as a <emphasis>down thread</emphasis>) for messages passed down from
+ higher layers. A higher layer might be another protocol higher in the stack, or the
+ application itself if the protocol is at the top of the stack. If <literal>true</literal>
+ (the default), when a message is passed down from a higher layer, the calling thread
+ places the message in the protocol's queue and then returns immediately. The protocol's
+ down thread is responsible for reading messages off the queue, performing any required
+ protocol-specific processing, and passing the message to the next protocol in the stack.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><varname>up_thread</varname></term>
+ <para>
+ Conceptually similar to <varname>down_thread</varname>, except that here the queue and
+ thread are for messages received from lower layers in the protocol stack.
+ </para>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ Generally, <varname>up_thread</varname> and <varname>down_thread</varname> should
+ be set to <literal>false</literal>.
</para>
-<itemizedlist>
- <listitem>
- <para><literal>down_thread</literal> whether the protocol should create an internal queue and a queue processing thread (aka the down_thread) for messages passed down from higher layers. The higher layer could be another protocol higher in the stack, or the application itself, if the protocol is the top one on the stack. If true (the default), when a message is passed down from a higher layer, the calling thread places the message in the protocol's queue, and then returns immediately. The protocol's down_thread is responsible for reading messages off the queue, doing whatever protocol-specific processing is required, and passing the message on to the next protocol in the stack.
- </para>
- </listitem>
- <listitem>
- <para><literal>up_thread</literal> is conceptually similar to down_thread, but here the queue and thread are for messages received from lower layers in the protocol stack.
- </para>
- </listitem>
-</itemizedlist>
-<para>Generally speaking, <literal>up_thread</literal> and <literal>down_thread</literal> should be set to false.
-</para>
</section>
-
+<!--tsuzukeru-->
<section id="jbosscache-jgroups-transport">
<title>Transport Protocols</title>
<para>The transport protocols send messages from one cluster node to another (unicast) or from cluster
More information about the jboss-cvs-commits
mailing list