[jboss-cvs] JBossAS SVN: r104843 - projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sun May 16 20:45:51 EDT 2010
Author: laubai
Date: 2010-05-16 20:45:51 -0400 (Sun, 16 May 2010)
New Revision: 104843
Modified:
projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Book_Info.xml
projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
Log:
JBPAPP-2648 Corrected issues and updated for brew build.
Modified: projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Book_Info.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2010-05-17 00:20:35 UTC (rev 104842)
+++ projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Book_Info.xml 2010-05-17 00:45:51 UTC (rev 104843)
@@ -7,7 +7,7 @@
<subtitle>for Use with JBoss Enterprise Web Platform 5.0.1</subtitle>
<edition>1</edition>
<issuenum>1</issuenum>
- <pubsnumber>2.05</pubsnumber>
+ <pubsnumber>2.07</pubsnumber>
<productname>JBoss Enterprise Web Platform</productname>
<productnumber>5.0</productnumber>
<!-- <pubdate>, 2009</pubdate> -->
Modified: projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
===================================================================
--- projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2010-05-17 00:20:35 UTC (rev 104842)
+++ projects/docs/enterprise/EWP_5.0.1/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2010-05-17 00:45:51 UTC (rev 104843)
@@ -1573,19 +1573,17 @@
This section addresses the usual case: a cluster of three machines, each of which has, for example, an HAPartition deployed alongside JBoss Cache for web session clustering. The HAPartition channels should not communicate with the JBoss Cache channels. Ensuring proper isolation of these channels is straightforward, and is usually handled by the application server without any alterations on the part of the user.
</para>
<para>
- To isolate channels for different services from each other on the same set of application server instances, each channel must have its own group name. The configurations that ship with JBoss Application Server ensure that this is the case. However, if you create a custom service that uses JGroups directly, you must use a unique group name. If you create a custom JBoss Cache configuration, ensure that you provide a unique value in the <literal>clusterName</literal> configuration property.
+ To isolate channels for different services from each other on the same set of application server instances, each channel must have its own group name. The configurations that are shipped with JBoss Enterprise Web Platform ensure that this is the case. However, if you create a custom service that uses JGroups directly, you must use a unique group name. If you create a custom JBoss Cache configuration, ensure that you provide a unique value in the <varname>clusterName</varname> configuration property.
</para>
- <para>
- In releases prior to JBoss Application Server 5, different channels running in the same application server also had to use unique multicast ports.
- With the JGroups shared transport introduced in JBoss AS 5 (see
- <xref linkend="clustering-blocks-jgroups-sharedtransport"/>), it is
- now common for multiple channels to use the same tranpsort protocol and its sockets.
- This makes configuration easier, which is one of the main benefits of the shared
- transport. However, if you decide to create your own custom JGroups protocol
- stack configuration, be sure to configure its transport protocols with a multicast port
- that is different from the ports used in other protocol stacks.
- </para>
+ <para>
+ JGroups uses shared transport by default, so it is common for multiple channels
+ to use the same transport protocol and its sockets.
+ This makes configuration easier, which is one of the main benefits of the shared
+ transport. However, if you decide to create your own custom JGroups protocol
+ stack configuration, be sure to configure its transport protocols with a multicast port
+ that is different from the ports used in other protocol stacks.
+ </para>
<section id="clustering-jgroups-isolation-group-name"><title>Changing the Group Name</title>
@@ -1606,8 +1604,8 @@
<section><title>Changing the multicast address and port</title>
<para>
The <literal>-u</literal> (or <literal>--udp</literal>) command line switch may be used to control the multicast address used by the JGroups channels opened by all standard AS services.
-<screen><![CDATA[/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production]]></screen>
-This switch sets the <literal>jboss.partition.udpGroup</literal> system property, which is referenced in all of the standard protocol stack configurations in JBoss AS:
+<screen><![CDATA[./run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production]]></screen>
+This switch sets the <literal>jboss.partition.udpGroup</literal> system property, which is referenced in all of the standard protocol stack configurations in JBoss Enterprise Web Platform:
</para>
<programlisting><![CDATA[<UDP mcast_addr="${jboss.partition.udpGroup:228.1.2.3}" ....]]></programlisting>
@@ -1628,14 +1626,14 @@
to isolate clusters; the channels running in the different clusters
must also use different multicast ports. Unfortunately, setting the
multicast ports is not as simple as <code>-g</code> and
- <literal>-u</literal>. By default, a JBoss AS instance
+ <literal>-u</literal>. By default, a JBoss Enterprise Web Platform instance
running the <literal>production</literal> configuration will use up to two different instances of
the JGroups UDP transport protocol, and will therefore open two
multicast sockets. You can control the ports those sockets use
by using system properties on the command line. For example,
</para>
<programlisting>
-/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production \\
+./run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production \\
-Djboss.jgroups.udp.mcast_port=12345
</programlisting>
<!-- -Djboss.messaging.datachanneludpport=23456-->
@@ -1648,7 +1646,8 @@
<para>The set of JGroups protocol stack configurations included in the
<filename>$JBOSS_HOME/server/production/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</filename>
file includes a number of other example protocol stack configurations that
- the standard JBoss AS distribution doesn't actually use. Those configurations also
+ the standard JBoss Enterprise Web Platform distribution doesn't actually use.
+ Those configurations also
use system properties to set any multicast ports. So, if you reconfigure some
AS service to use one of those protocol stack configurations, use the
appropriate system property to control the port from the command line.
More information about the jboss-cvs-commits
mailing list