[jboss-cvs] JBossAS SVN: r97719 - projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Dec 11 03:21:39 EST 2009
Author: laubai
Date: 2009-12-11 03:21:38 -0500 (Fri, 11 Dec 2009)
New Revision: 97719
Modified:
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JMS.xml
projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
Log:
Added changes for JBPAPP-2649, 2648, 2647, 2646, 2645, 2644, 2643, 2642.
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Building_Blocks.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -11,7 +11,7 @@
<figure id="clustering-as-arch.fig">
<title>The JBoss Enterprise Application Platform clustering architecture</title>
<mediaobject>
- <imageobject>
+ <imageobject><!--replace with https://engineering.redhat.com/rt3/Ticket/Display.html?id=55884-->
<imagedata align="center" fileref="images/clustering-as-arch.png" />
</imageobject>
</mediaobject>
@@ -25,10 +25,10 @@
<para><emphasis role="bold">JBoss Cache</emphasis> is a highly flexible
clustered transactional caching library. Many Enterprise Application Platform clustering services
- need to cache some state in memory while 1) ensuring for high availability
+ need to cache some state in memory while (1) ensuring for high availability
purposes that a backup copy of that state is available on another node
if it can't otherwise be recreated (e.g. the contents of a web session)
- and 2) ensuring that the data cached on each node in the cluster is consistent.
+ and (2) ensuring that the data cached on each node in the cluster is consistent.
JBoss Cache handles these concerns for most JBoss Enterprise Application Platform clustered services.
JBoss Cache uses JGroups to handle its group communication requirements.
<emphasis role="bold">POJO Cache</emphasis> is an extension of the
@@ -81,7 +81,7 @@
<section id="clustering-blocks-jgroups-stdconfigs">
<title>Standard Protocol Stack Configurations</title>
<para>
- The standard protocol stack configurations that ship with Enterprise Application Platform 5 are described below. Note that not all of these are actually used; many are included as a convenience to users who may wish to alter the default server configuration. The configurations actually used in a stock Enterprise Application Platform 5 <emphasis role="bold">all</emphasis> config are <literal>udp</literal>, <literal>jbm-control</literal> and <literal>jbm-data</literal>, with all clustering services other than JBoss Messaging using <literal>udp</literal>.
+ The standard protocol stack configurations that ship with Enterprise Application Platform 5 are described below. Note that not all of these are actually used; many are included as a convenience to users who may wish to alter the default server configuration. The configurations actually used in a stock Enterprise Application Platform 5 <emphasis role="bold">all</emphasis> configuration are <literal>udp</literal>, <literal>jbm-control</literal> and <literal>jbm-data</literal>, with all clustering services other than JBoss Messaging using <literal>udp</literal>.
</para>
<para>
You can add a new stack configuration by adding a new <literal>stack</literal> element to the <literal>server/all/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml</literal> file. You can alter the behavior of an existing configuration by editing this file. Before doing this though, have a look at the other standard configurations the Enterprise Application Platform ships; perhaps one of those meets your needs. Also, please note that before editing a configuration you should understand what services are using that configuration; make sure the change you are making is appropriate for all affected services. If the change isn't appropriate for a particular service, perhaps its better to create a new configuration and change some services to use that new configuration.
@@ -92,14 +92,14 @@
<para>
<emphasis role="bold">udp</emphasis></para>
<para>
- UDP multicast based stack meant to be shared between different channels.Message bundling is disabled, as it can add latency to synchronous group RPCs. Services that only make asynchronous RPCs (for example, JBoss Cache configured for REPL_Enterprise Application PlatformYNC) and do so in high volume may be able to improve performance by configuring their cache to use the <literal>udp-async</literal> stack below. Services that only make synchronous RPCs (for example JBoss Cache configured for REPL_SYNC or INVALIDATION_SYNC) may be able to improve performance by using the <literal>udp-sync</literal> stack below, which does not include flow control.
+ UDP multicast based stack meant to be shared between different channels. Message bundling is disabled, as it can add latency to synchronous group RPCs. Services that only make asynchronous RPCs (for example, JBoss Cache configured for REPL_ASYNC) and do so in high volume may be able to improve performance by configuring their cache to use the <literal>udp-async</literal> stack below. Services that only make synchronous RPCs (for example JBoss Cache configured for REPL_SYNC or INVALIDATION_SYNC) may be able to improve performance by using the <literal>udp-sync</literal> stack below, which does not include flow control.
</para>
</listitem>
<listitem>
<para>
<emphasis role="bold">udp-async</emphasis></para>
<para>
- Same as the default <literal>udp</literal> stack above, except message bundling is enabled in the transport protocol (<literal>enable_bundling=true</literal>). Useful for services that make high-volume asynchronous RPCs (e.g. high volume JBoss Cache instances configured for REPL_Enterprise Application PlatformYNC) where message bundling may improve performance.
+ Same as the default <literal>udp</literal> stack above, except message bundling is enabled in the transport protocol (<literal>enable_bundling=true</literal>). Useful for services that make high-volume asynchronous RPCs (e.g. high volume JBoss Cache instances configured for REPL_ASYNC) where message bundling may improve performance.
</para>
</listitem>
<listitem>
@@ -128,7 +128,7 @@
<emphasis role="bold">jbm-control</emphasis>
</para>
<para>
- Stack optimized for the JBoss Messaging Control Channel. By default uses the same UDP transport protocol config as is used for the default 'udp' stack defined above. This allows the JBoss Messaging Control Channel to use the same sockets, network buffers and thread pools as are used by the other standard JBoss Enterprise Application Platform clustered services (see <xref linkend="clustering-blocks-jgroups-sharedtransport"/>
+ Stack optimized for the JBoss Messaging Control Channel. By default uses the same UDP transport protocol configuration as is used for the default <literal>udp</literal> stack defined above. This allows the JBoss Messaging Control Channel to use the same sockets, network buffers and thread pools as are used by the other standard JBoss Enterprise Application Platform clustered services (see <xref linkend="clustering-blocks-jgroups-sharedtransport"/>)
</para>
</listitem>
<listitem>
@@ -136,7 +136,7 @@
<emphasis role="bold">jbm-data</emphasis>
</para>
<para>
- Stack optimized for the JBoss Messaging Data Channel. TCP-based
+ TCP-based stack optimized for the JBoss Messaging Data Channel.
</para>
</listitem>
</itemizedlist>
@@ -149,7 +149,7 @@
the Enterprise Application Platform has risen over the years, the need to share the resources
(particularly sockets and threads) used by these channels became
a glaring problem. A stock Enterprise Application Platform 5 <emphasis role="bold">all</emphasis>
- config will connect 4 JGroups channels during startup, and a total of
+ configuration will connect 4 JGroups channels during startup, and a total of
7 or 8 will be connected if distributable web apps, clustered EJB3
SFSBs and a clustered JPA/Hibernate second level cache are all used.
So many channels can consume a lot of resources, and can be a real
@@ -169,9 +169,9 @@
<para>
To configure a transport protocol for sharing, simply add a
<literal>singleton_name="someName"</literal> attribute to the protocol's
- configuration. All channels whose transport protocol config uses the
+ configuration. All channels whose transport protocol configuration uses the
same <literal>singleton_name</literal> value will share their transport.
- All other protocols in the stack will not be shared. The following
+ All other protocols in the stack will not be shared. <xref linkend="clustering-blocks-jgroups-sharedtp.fig"/>
illustrates 4 services running in a VM, each with its own channel.
Three of the services are sharing a transport; the fourth is using
its own transport.</para>
@@ -188,7 +188,7 @@
</figure>
<para>The protocol stack configurations used by the Enterprise Application Platform 5 ChannelFactory
- all have a singleton_name configured. In fact, if you add a stack to the
+ all have a <literal>singleton_name</literal> configured. In fact, if you add a stack to the
ChannelFactory that doesn't include a <literal>singleton_name</literal>,
before creating any channels for that stack, the ChannelFactory will
synthetically create a <literal>singleton_name</literal> by concatenating
@@ -203,11 +203,11 @@
provides the underlying distributed caching support used by many of the
standard clustered services in a JBoss Enterprise Application Platform cluster, including:
<itemizedlist>
- <listitem><para>Replication of clustered webapp sessions.</para></listitem>
- <listitem><para>Replication of clustered EJB3 Stateful Session beans.</para></listitem>
- <listitem><para>Clustered caching of JPA and Hibernate entities.</para></listitem>
- <listitem><para>Clustered Single Sign-On.</para></listitem>
- <listitem><para>The HA-JNDI replicated tree.</para></listitem>
+ <listitem><para>replication of clustered webapp sessions</para></listitem>
+ <listitem><para>replication of clustered EJB3 Stateful Session beans</para></listitem>
+ <listitem><para>clustered caching of JPA and Hibernate entities</para></listitem>
+ <listitem><para>clustered Single Sign-On</para></listitem>
+ <listitem><para>the HA-JNDI replicated tree</para></listitem>
<listitem><para>DistributedStateService</para></listitem>
</itemizedlist>
</para>
@@ -234,11 +234,11 @@
use them. They shouldn't be first-class deployments.</para></listitem>
<listitem><para>Services would find their cache via JMX lookups.
Using JMX for purposes other exposing management interfaces is just
- not the JBoss 5 way.</para></listitem>
+ not the JBoss Enterprise Application Platform 5 way.</para></listitem>
</itemizedlist>
</para>
- <para>In JBoss 5, the scattered cache deployments have been replaced
+ <para>In JBoss Enterprise Application Platform 5, the scattered cache deployments have been replaced
with a new <emphasis role="bold">CacheManager</emphasis> service,
deployed via the <literal>JBOSS_HOME/server/all/deploy/cluster/jboss-cache-manager.sar</literal>.
The CacheManager is a factory and registry for JBoss Cache instances.
@@ -288,20 +288,20 @@
<listitem>
<para><emphasis role="bold">mvcc-entity</emphasis></para>
- <para>A config appropriate for JPA/Hibernate entity/collection
+ <para>A configuration appropriate for JPA/Hibernate entity/collection
caching that uses JBC's MVCC locking (see notes below).</para>
</listitem>
<listitem>
<para><emphasis role="bold">optimistic-entity</emphasis></para>
- <para>A config appropriate for JPA/Hibernate entity/collection
+ <para>A configuration appropriate for JPA/Hibernate entity/collection
caching that uses JBC's optimistic locking (see notes below).
</para>
</listitem>
<listitem>
<para><emphasis role="bold">pessimistic-entity</emphasis></para>
- <para>A config appropriate for JPA/Hibernate entity/collection
+ <para>A configuration appropriate for JPA/Hibernate entity/collection
caching that uses JBC's pessimistic locking (see notes below).
</para>
</listitem>
@@ -322,21 +322,21 @@
<listitem>
<para><emphasis role="bold">local-query</emphasis></para>
- <para>A config appropriate for JPA/Hibernate query result caching.
+ <para>A configuration appropriate for JPA/Hibernate query result caching.
Does not replicate query results. DO NOT store the timestamp data
Hibernate uses to verify validity of query results in this cache.</para>
</listitem>
<listitem>
<para><emphasis role="bold">replicated-query</emphasis></para>
- <para>A config appropriate for JPA/Hibernate query result caching.
+ <para>A configuration appropriate for JPA/Hibernate query result caching.
Replicates query results. DO NOT store the timestamp data
Hibernate uses to verify validity of query result in this cache.</para>
</listitem>
<listitem>
<para><emphasis role="bold">timestamps-cache</emphasis></para>
- <para>A config appropriate for the timestamp data cached as part
+ <para>A configuration appropriate for the timestamp data cached as part
of JPA/Hibernate query result caching. A replicated timestamp cache
is required if query result caching is used, even if the query results
themselves use a non-replicating cache like <literal>local-query</literal>.</para>
@@ -344,7 +344,7 @@
<listitem>
<para><emphasis role="bold">mvcc-shared</emphasis></para>
- <para>A config appropriate for a cache that's shared for JPA/Hibernate
+ <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
advised configuration, since it requires cache mode REPL_SYNC,
which is the least efficient mode. Also requires a full state
@@ -355,7 +355,7 @@
<listitem>
<para><emphasis role="bold">optimistic-shared</emphasis></para>
- <para>A config appropriate for a cache that's shared for JPA/Hibernate
+ <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
advised configuration, since it requires cache mode REPL_SYNC,
which is the least efficient mode. Also requires a full state
@@ -366,7 +366,7 @@
<listitem>
<para><emphasis role="bold">pessimistic-shared</emphasis></para>
- <para>A config appropriate for a cache that's shared for JPA/Hibernate
+ <para>A configuration appropriate for a cache that's shared for JPA/Hibernate
entity, collection, query result and timestamp caching. Not an
advised configuration, since it requires cache mode REPL_SYNC,
which is the least efficient mode. Also requires a full state
@@ -407,12 +407,12 @@
<para>The CacheManager also supports aliasing of caches; i.e.
allowing caches registered under one name to be looked up under a
different name. Aliasing is useful for sharing caches between
- services whose configuration may specify different cache config
+ services whose configuration may specify different cache configuration
names. It's also useful for supporting legacy EJB3 application
configurations ported over from Enterprise Application Platform 4.</para>
<para>Aliases can be configured by editing the "CacheManager"
bean in the <literal>jboss-cache-manager-jboss-beans.xml</literal>
- file. The following redacted config shows the standard aliases in
+ file. The following redacted configuration shows the standard aliases in
Enterprise Application Platform 5:</para>
<programlisting><![CDATA[
@@ -421,7 +421,7 @@
. . .
<!-- Aliases for cache names. Allows caches to be shared across
- services that may expect different cache config names. -->
+ services that may expect different cache configuration names. -->
<property name="configAliases">
<map keyClass="java.lang.String" valueClass="java.lang.String">
<!-- Use the HAPartition cache for ClusteredSSO caching -->
@@ -516,13 +516,13 @@
</property>
</bean>]]>
</programlisting>
- <para>Much of the above is boilerplate; below we'll touch on the key points relevant to end users. There are two beans defined above, the <literal>HAPartitionCacheHandler</literal> and the <literal>HAPartition</literal> itself.</para>
+ <para>Much of the above is generic; below we'll touch on the key points relevant to end users. There are two beans defined above, the <literal>HAPartitionCacheHandler</literal> and the <literal>HAPartition</literal> itself.</para>
<para>The <literal>HAPartition</literal> bean itself exposes the following configuration properties:</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">partitionName</emphasis> is an optional attribute to specify the
- name of the cluster. Its default value is <literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. --partition) command line switch to set this value at JBoss startup.</para>
+ name of the cluster. Its default value is <literal>DefaultPartition</literal>. Use the <literal>-g </literal> (a.k.a. --partition) command line switch to set this value at server startup.</para>
</listitem>
<listitem>
<para><emphasis role="bold">nodeAddress</emphasis> is unused and can be ignored.</para>
@@ -596,9 +596,9 @@
nodes in a cluster.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">HEnterprise Application Platformingleton</emphasis></para>
+ <para><emphasis role="bold">HASingleton</emphasis></para>
<para>Here the keys are the names of the various services that need to
- function as High Availablity Singletons (see <!-- <xref linkend="clustering-hasingleton"/> --> the HEnterprise Application Platformingleton chapter).
+ function as High Availablity Singletons (see <!-- <xref linkend="clustering-hasingleton"/> --> the HASingleton chapter).
The value object each node stores in the DRM is simply a String that
acts as a token to indicate that the node has the service deployed, and
thus is a candidate to become the "master" node for the HA singleton
@@ -613,7 +613,7 @@
something under that service's key, and services don't have to be
deployed homogeneously across the cluster. The DRM is thus useful as a
mechanism for understanding a service's "topology" around the cluster
- -- which nodes have the service deployed.</para>
+ — which nodes have the service deployed.</para>
</section>
<section id="clustering-hapartition-distributedstate">
@@ -627,7 +627,7 @@
compatibility reasons, but new applications should not use it; they
should use the much more sophisticated JBoss Cache instead.
</para>
- <para>In JBoss 5 the <literal>DistributedState</literal> service actually
+ <para>In JBoss Enterprise Application Platform 5 the <literal>DistributedState</literal> service actually
delegates to an underlying JBoss Cache instance.</para>
</section>
@@ -636,8 +636,8 @@
<para>Custom services can also use make use of HAPartition to handle
interactions with the cluster. Generally the easiest way to do this
- is to extend the <literal>org.jboss.ha.framework.server.HEnterprise Application PlatformerviceImpl</literal>
- base class, or the <literal>org.jboss.ha.jxm.HEnterprise Application PlatformerviceMBeanSupport</literal>
+ is to extend the <literal>org.jboss.ha.framework.server.HAServiceImpl</literal>
+ base class, or the <literal>org.jboss.ha.jxm.HAServiceMBeanSupport</literal>
class if JMX registration and notification support are desired.
</para>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Concepts.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -59,7 +59,7 @@
<title>Service Architectures</title>
<para>The clustering topography defined by the JGroups configuration on each node is of great importance to system administrators. But for most application developers, the greater concern is probably the cluster
architecture from a client application's point of view. Two basic clustering
- architectures are used with JBoss Enterprise Application Platform: client-side interceptors (a.k.a smart
+ architectures are used with JBoss Enterprise Application Platform: client-side interceptors (a.k.a. smart
proxies or stubs) and external load balancers. Which architecture your
application will use will depend on what type of client you have.
</para>
@@ -76,7 +76,7 @@
object. The proxy automatically routes the call across the network where
it is invoked against service objects managed in the server. The proxy
object figures out how to find the appropriate server node, marshal call
- parameters, un-marshall call results, and return the result to the caller
+ parameters, unmarshal call results, and return the result to the caller
client. In a clustered environment, the server-generated proxy object includes an
interceptor that understands how to route calls to multiple nodes in the
cluster.
@@ -147,7 +147,7 @@
</section>
<section id="clustering-concepts-balancepolicy">
- <title>Load-Balancing Policies</title>
+ <title>Load Balancing Policies</title>
<para>
Both the JBoss client-side interceptor (stub) and load balancer use load balancing policies to determine to which server node a new request should be sent. In this section, let's go over the load balancing policies available in JBoss Enterprise Application Platform.
</para>
@@ -165,7 +165,7 @@
<listitem>
<para>
- Random-Robin: for each call the target node is randomly selected from the list. Implemented by <literal>org.jboss.ha.framework.interfaces.RoundRobin</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RoundRobin</literal> (EJB3).
+ Random-Robin: for each call the target node is randomly selected from the list. Implemented by <literal>org.jboss.ha.framework.interfaces.RandomRobin</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.RandomRobin </literal> (EJB3).
</para>
</listitem>
<listitem>
@@ -177,13 +177,13 @@
<listitem>
<para>
- First Available Identical All Proxies: has the same behaviour as the "First Available" policy but the elected target node is shared by all proxies in the same client-side VM that are associated with the same target service. So if a particular client downloads two proxies for the same target service (e.g. an EJB), each proxy will use the same target. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies</literal> (EJB3).
+ First Available Identical All Proxies: has the same behavior as the "First Available" policy but the elected target node is shared by all proxies in the same client-side VM that are associated with the same target service. So if a particular client downloads two proxies for the same target service (e.g. an EJB), each proxy will use the same target. Implemented by <literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal> (legacy) and <literal>org.jboss.ha.client.loadbalance.aop.FirstAvailableIdenticalAllProxies</literal> (EJB3).
</para>
</listitem>
</itemizedlist>
<para>
- Each of the above is an implementation of the org.jboss.ha.framework.interfaces.LoadBalancePolicy interface; users are free to write their own implementation of this simple interface if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services.
+ Each of the above is an implementation of the <classname>org.jboss.ha.framework.interfaces.LoadBalancePolicy</classname> interface; users are free to write their own implementation of this simple interface if they need some special behavior. In later sections we'll see how to configure the load balance policies used by different services.
</para>
</section>
<section><title>External load balancer architecture</title>
@@ -211,7 +211,7 @@
<listitem>
<para>
- Transaction-Sticky First Available Identical All Proxies: Transaction-sticky variant of First Available Identical All Proxies. Implemented by <literal>org.jboss.ha.framework.interfaces.</literal> <literal>TransactionStickyFirstAvailableIdenticalAllProxies</literal>.
+ Transaction-Sticky First Available Identical All Proxies: Transaction-sticky variant of First Available Identical All Proxies. Implemented by <literal>org.jboss.ha.framework.interfaces.TransactionStickyFirstAvailableIdenticalAllProxies</literal>.
</para>
</listitem>
</itemizedlist>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_Deployment.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -65,7 +65,7 @@
directory is the responsibility of a special service, the
<literal>HASingletonDeployer</literal> bean
(which itself is deployed via the
- deploy/deploy-hasingleton-jboss-beans.xml file.) The
+ deploy/deploy-hasingleton-jboss-beans.xml file). The
HASingletonDeployer service is itself an HA Singleton, one whose
provided service, when it becomes master, is to deploy the
contents of deploy-hasingleton; and whose service, when it stops
@@ -137,6 +137,7 @@
boolean isMasterNode();
}
+
public class HASingletonExample implements HASingletonExampleMBean
{
private boolean isMasterNode = false;
@@ -231,9 +232,9 @@
The way it works is that a BarrierController is deployed along with the
HASingletonDeployer and listens for JMX
notifications from it. A BarrierController is a relatively
- simple Mbean that can subscribe to receive any JMX notification
+ simple MBean that can subscribe to receive any JMX notification
in the system. It uses the received notifications to control the
- lifecycle of a dynamically created Mbean called the Barrier. The
+ lifecycle of a dynamically created MBean called the Barrier. The
Barrier is instantiated, registered and brought to the CREATE
state when the BarrierController is deployed. After that, the
BarrierController starts and stops the Barrier when matching JMX
@@ -309,7 +310,7 @@
}
]]></programlisting>
<para>
- JBoss ships with 2 election policies:
+ JBoss Enterprise Application Platform ships with two election policies:
</para>
<variablelist>
<varlistentry>
@@ -362,7 +363,7 @@
</para>
<para>
- Farming is enabled by default in the <literal>all</literal> configuration in JBoss AS and thus requires no manual setup.
+ Farming is enabled by default in the <literal>all</literal> configuration in JBoss Enterprise Application Platform and thus requires no manual setup.
The required <filename>farm-deployment-jboss-beans.xml</filename> and <filename>timestamps-jboss-beans.xml</filename> configuration files are located in the <literal>deploy/cluster</literal> directory.
If you want to enable farming in a custom configuration, simply copy these files to the corresponding JBoss deploy directory <literal>$JBOSS_HOME/server/your_own_config/deploy/cluster</literal>.
Make sure that your custom configuration has clustering enabled.
@@ -416,7 +417,7 @@
<para>
<emphasis role="bold">synchronizationPolicy</emphasis> decides how to handle content additions, reincarnations, updates, or removals from nodes attempting to join the cluster or from cluster merges.
The policy is consulted on the "authoritative" node, i.e. the master node for the service on the cluster.
- <emphasis>Reincarnation</emphasis> refers to the phenomenon where a newly started node may contain an application in its <literal>farm</literal> directory that was previously removed by the farming service but might still exist on the starting node if it was not running when the removal took place.
+ <emphasis>Reincarnation</emphasis> refers to the phenomenon where a newly started node may contain an application in its <literal>farm/</literal> directory that was previously removed by the farming service but might still exist on the starting node if it was not running when the removal took place.
The default synchronization policy is defined as follows:
</para>
<programlisting><![CDATA[
@@ -465,14 +466,14 @@
provide. For instance, in a stateful session bean application, the session state must be
synchronized among all bean instances across all nodes, so that the client application reaches the
same session state no matter which node serves the request. In an entity bean application, the bean
- object sometimes needs to be cached across the cluster to reduce the database load. Currently, the state replication and distributed cache services in JBoss AS are provided via three ways: the <literal>HASessionState</literal> Mbean, the <literal>DistributedState</literal> MBean and the JBoss Cache framework.</para>
+ object sometimes needs to be cached across the cluster to reduce the database load. Currently, the state replication and distributed cache services in JBoss AS are provided via three ways: the <literal>HASessionState</literal> MBean, the <literal>DistributedState</literal> MBean and the JBoss Cache framework.</para>
<itemizedlist>
<listitem>
<para>The <literal>HASessionState</literal> MBean is a legacy service that provides session replication and distributed cache services for EJB 2.x stateful session beans. The MBean is defined in the <literal>all/deploy/cluster-service.xml</literal> file. We will show its configuration options in the EJB 2.x stateful session bean section later.</para>
</listitem>
<listitem>
<para>
- The <literal>DistributedState</literal> Mbean is a legacy service built on the HAPartition service. It is supported for backwards compatibility reasons, but new applications should not use it; they should use the much more sophisticated JBoss Cache instead.
+ The <literal>DistributedState</literal> MBean is a legacy service built on the HAPartition service. It is supported for backwards compatibility reasons, but new applications should not use it; they should use the much more sophisticated JBoss Cache instead.
</para>
</listitem>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_HTTP.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -12,14 +12,14 @@
<para>Session state replication</para>
</listitem>
<listitem>
- <para>Load-balancing of incoming invocations</para>
+ <para>Load-balancing HTTP Requests</para>
</listitem>
</itemizedlist>
<para>State replication is directly handled by JBoss. When you run JBoss
in the <literal>all</literal> configuration, session state replication is
enabled by default. Just configure your web application as
<literal><distributable></literal> in its <filename>web.xml</filename> (see <xref linkend="clustering-http-state"/>),
- deploy it, and its session state is automtically replicated across all
+ deploy it, and its session state is automatically replicated across all
JBoss instances in the cluster.</para>
<para>However, load-balancing is a different story; it is not handled by
JBoss itself and requires an external load balancer. This function could
@@ -58,16 +58,14 @@
<section id="clustering-http-download">
<title>Download the software</title>
<para>First of all, make sure that you have Apache installed. You can download Apache directly from
- Apache web site at <literal>http://httpd.apache.org/</literal>. Its installation is pretty
- straightforward and requires no specific configuration. As several versions of Apache exist, we
- advise you to use the latest stable 2.2.x version. We will consider, for the next sections, that you have installed
- Apache in the <literal>APACHE_HOME</literal> directory.</para>
- <para>Next, download mod_jk binaries. Several versions of mod_jk exist as well. We strongly advise you
- to use mod_jk 1.2.x, as both mod_jk and mod_jk2 are deprecated, unsupported and no further
- development is going on in the community. The mod_jk 1.2.x binary can be downloaded from
- <literal>http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</literal>. Rename the
- downloaded file to <literal>mod_jk.so</literal> and copy it under
- <literal>APACHE_HOME/modules/</literal>.</para>
+ Apache web site at <ulink url="http://httpd.apache.org/">http://httpd.apache.org/</ulink>. Its installation is pretty
+ straightforward and requires no specific configuration. As several versions of Apache exist, we
+ advise you to use the latest stable 2.2.x version. We will assume, for the next sections, that you have installed
+ Apache in the <literal>APACHE_HOME</literal> directory.</para>
+ <para>Next, download mod_jk binaries. Several versions of mod_jk exist as well. We strongly advise the use of mod_jk 1.2.x, as both earlier versions of mod_jk, and mod_jk2, are deprecated, unsupported and no further
+ development is going on in the community. The mod_jk 1.2.x binary can be downloaded from <ulink url="http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/">http://www.apache.org/dist/jakarta/tomcat-connectors/jk/binaries/</ulink>. Rename the
+ downloaded file to <literal>mod_jk.so</literal> and copy it under
+ <literal>APACHE_HOME/modules/</literal>.</para>
</section>
<section>
<title>Configure Apache to load mod_jk</title>
@@ -182,7 +180,7 @@
# Define Node2
# modify the host as your host IP or DNS name.
worker.node2.port=8009
-worker.node2.host= node2.mydomain.com
+worker.node2.host=node2.mydomain.com
worker.node2.type=ajp13
worker.node2.lbfactor=1
worker.node2.cachesize=10
@@ -197,7 +195,7 @@
worker.status.type=status
</programlisting>
<para>Basically, the above file configures mod_jk to perform weighted round-robin load balancing with
- sticky sessions between two servlet containers (that is, JBoss AS instances) node1 and node2 listening on port
+ sticky sessions between two servlet containers (that is, JBoss Enterprise Application Platform instances) node1 and node2 listening on port
8009.</para>
<para>In the <literal>workers.properties</literal> file, each node is defined using the
<literal>worker.XXX</literal> naming convention where <literal>XXX</literal> represents an
@@ -210,12 +208,12 @@
Servlet container (i.e. the number of concurrent requests it will forward to the Servlet container).
Make sure this number does not outnumber the number of threads configured on the AJP13 connector of
the Servlet container. Please review
- <literal>http://jakarta.apache.org/tomcat/connectors-doc/config/workers.html</literal> for
+ <ulink url="http://tomcat.apache.org/connectors-doc/reference/workers.html">>http://tomcat.apache.org/connectors-doc/reference/workers.html</ulink> for
comments on <literal>cachesize</literal> for Apache 1.3.x.</para>
<para>The last part of the <literal>conf/workers.properties</literal> file defines the loadbalancer
worker. The only thing you must change is the
<literal>worker.loadbalancer.balanced_workers</literal> line: it must list all workers previously
- defined in the same file: load-balancing will happen over these workers.</para>
+ defined in the same file. Load-balancing will happen over these workers.</para>
<para>The <literal>sticky_session</literal> property specifies the cluster behavior for HTTP sessions.
If you specify <literal>worker.loadbalancer.sticky_session=0</literal>, each request will be load
balanced between node1 and node2; i.e., different requests for the same session will go to different servers. But when a user opens a session on one server, it is always necessary to always forward this user's requests to the same server, as long as that server is available. This is called a "sticky session", as the client is always using the same server he reached on his first request. To enable session stickiness, you need to set
@@ -227,7 +225,7 @@
</section>
<section id="clustering-http-jboss">
<title>Configuring JBoss to work with mod_jk</title>
- <para>Finally, we must configure the JBoss AS instances on all clustered nodes so that they can
+ <para>Finally, we must configure the JBoss Enterprise Application Platform instances on all clustered nodes so that they can
expect requests forwarded from the mod_jk loadbalancer.</para>
<para>On each clustered JBoss node, we have to name the node according to the name specified in
<literal>workers.properties</literal>. For instance, on JBoss instance node1, edit the
@@ -236,15 +234,15 @@
<literal><Engine></literal> element and add an attribute <literal>jvmRoute</literal>:</para>
<programlisting>
<Engine name="jboss.web" defaultHost="localhost" jvmRoute="node1">
-... ...
+...
</Engine>
</programlisting>
<para>You also need to be sure the AJP connector in server.xml is enabled (i.e., uncommented). It is enabled by default.
</para>
<programlisting><![CDATA[
<!-- Define an AJP 1.3 Connector on port 8009 -->
-+<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"
-+ redirectPort="8443" />]]>
+<Connector protocol="AJP/1.3" port="8009" address="${jboss.bind.address}"
+ redirectPort="8443" />]]>
</programlisting>
<!--<para>Then, for each JBoss Tomcat instance in the cluster, we need to tell it that mod_jk is in use, so it can properly manage the <literal>jvmRoute</literal> appended to its session cookies so that mod_jk can properly route incoming requests. Edit the
@@ -255,7 +253,7 @@
<programlisting>
<attribute name="UseJK">true</attribute>
</programlisting>-->
- <para>At this point, you have a fully working Apache+mod_jk load-balancer setup that will balance call
+ <para>At this point, you have a fully working Apache with mod_jk load-balancer setup that will balance call
to the Servlet containers of your cluster while taking care of session stickiness (clients will
always use the same Servlet container).</para>
<note>
@@ -407,7 +405,7 @@
and needs to be replicated. This element has 3 valid values:</para>
<itemizedlist>
<listitem>
- <para><emphasis role="bold">SET_AND_GET</emphasis> is conservative but not optimal (performance-wise): it will always replicate session data even if its content has not been modified but simply accessed. This setting made (a little) sense in AS 4 since using it was a way to ensure that every request triggered replication of the session's timestamp. Since setting <literal>max_unreplicated_interval</literal> to 0 accomplishes the same thing at much lower cost, using <literal>SET_AND_GET</literal> makes no sense with AS 5.</para>
+ <para><emphasis role="bold">SET_AND_GET</emphasis> is conservative but not optimal (performance-wise): it will always replicate session data even if its content has not been modified but simply accessed. This setting made (a little) sense in AS 4 since using it was a way to ensure that every request triggered replication of the session's timestamp. Since setting <literal>max_unreplicated_interval</literal> to 0 accomplishes the same thing at much lower cost, using <literal>SET_AND_GET</literal> makes no sense with Enterprise Application Platform 5.</para>
</listitem>
<listitem>
<para><emphasis role="bold">SET_AND_NON_PRIMITIVE_GET</emphasis> is conservative but will only replicate if an object of a non-primitive type has been accessed (i.e. the object is not of a well-known immutable JDK type such as <literal>Integer</literal>, <literal>Long</literal>, <literal>String</literal>, etc.) This is the default value.</para>
@@ -435,7 +433,7 @@
JBoss Cache configuration that should be used for storing distributable
sessions and replicating them around the cluster. This element lets web applications that require
different caching characteristics specify the use of separate, differently
- configured, JBoss Cache instances. In JBoss AS 4 the cache to use was a server-wide
+ configured, JBoss Cache instances. In JBoss Enterprise Application Platform 4 the cache to use was a server-wide
configuration that could not be changed per web application. The default value is <literal>standard-session-cache</literal>
if the <literal>replication-granularity</literal> is not <literal>FIELD</literal>,
<literal>field-granularity-session-cache</literal> if it is. See <xref linkend="clustering-http-state-cacheconfig"/>
@@ -520,9 +518,9 @@
<literal>ClusteredSessionNotificationPolicy</literal> gives the application
author fine-grained control over what notifications are issued.</para>
- <para>In JBoss AS 5.0.0.GA the default value if not explicitly set is the
+ <para>In previous releases, the default value if not explicitly set is the
<literal>LegacyClusteredSessionNotificationPolicy</literal>, which implements
- the behavior in previous JBoss versions. In JBoss AS 5.1.0, this was
+ the behavior in previous JBoss versions. In JBoss Enterprise Application Platform 5, this was
changed to <literal>IgnoreUndeployLegacyClusteredSessionNotificationPolicy</literal>,
which implements the same behavior except during undeployment,
during which no <literal>HttpSessionListener</literal> and
@@ -536,7 +534,7 @@
relatively unused sessions from memory while storing them in persistent
storage. If a passivated session is requested by a client, it can be
"activated" back into memory and removed from the persistent store.
- JBoss AS 5 supports passivation of HttpSessions from web applications whose
+ JBoss Enterprise Application Platform 5 supports passivation of HttpSessions from web applications whose
<literal>web.xml</literal> includes the <literal>distributable</literal>
tag (i.e. clustered web applications).</para>
@@ -730,7 +728,7 @@
</section>
<section id="clustering-http-field">
- <title>Using FIELD level replication</title>
+ <title>Using FIELD-level replication</title>
<para>FIELD-level replication only replicates modified data fields inside objects stored in the session. It can reduce the data traffic between clustered nodes, and hence improve the performance of the whole cluster. To use FIELD-level replication, you must first prepare (that is, bytecode enhance) your Java class to allow the session cache to detect when fields in cached objects have been changed and need to be replicated.
</para>
<para>
@@ -738,7 +736,7 @@
</para>
<programlisting><![CDATA[
-@@org.jboss.cache.pojo.annotation.Replicable
+ at org.jboss.cache.pojo.annotation.Replicable
public class Address
{
...
@@ -762,16 +760,16 @@
]]></programlisting>
<para>There is no need to annotate <literal>Student</literal>. POJO Cache will recognize it as @Replicable because it is a sub-class of <literal>Person</literal>.</para>
-<para>JBoss AS 5 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
+<para>JBoss Enterprise Application Platform 5 requires JDK 5 at runtime, but some users may still need to build their projects using JDK 1.4. In this case, annotating classes can be done via JDK 1.4 style annotations embedded in JavaDocs. For example:
</para>
<programlisting>/**
* Represents a street address.
- * @@org.jboss.cache.pojo.annotation.Replicable
+ * @org.jboss.cache.pojo.annotation.Replicable
*/
- public class Address
+public class Address
{
...
}
@@ -813,7 +811,7 @@
<para>Later, a different servlet could update the family's postal code:</para>
<programlisting>
Person wife = (Person)session.getAttribute("wife");
-wife.getAddress().setPostalCode(getPostalCode(request)); // this will update and replicate the postal code.
+wife.getAddress().setPostalCode(getPostalCode(request)); // this will update and replicate the postal code
</programlisting>
<para>Notice that in there is no need to call <literal>session.setAttribute()</literal> after you make changes to
@@ -827,7 +825,7 @@
<section id="clustering-http-sso">
- <title>Using Clustered Single Sign On</title>
+ <title>Using Clustered Single Sign-on (SSO)</title>
<para>JBoss supports clustered single sign-on, allowing a user to authenticate
to one web application and to be recognized on all web
@@ -922,7 +920,7 @@
<section id="clustering-sso-behavior">
<title>SSO Behavior</title>
- <para>The user will not be challenged as long as he accesses only
+ <para>The user will not be challenged as long as they access only
unprotected resources in any of the web applications on the virtual host.</para>
<para>Upon access to a protected resource in any web app, the user will
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JGroups.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -69,14 +69,14 @@
<para>The following is an example protocol stack configuration from
<filename>jgroups-channelfactory-stacks.xml</filename>:</para>
-<programlisting><![CDATA[<stack name="udp-async"
+<programlisting><![CDATA[<stack name="udp-async"
description="Same as the default 'udp' stack above, except message bundling
is enabled in the transport protocol (enable_bundling=true).
Useful for services that make high-volume asynchronous
RPCs (e.g. high volume JBoss Cache instances configured
- for REPL_ASYNC) where message bundling may improve performance.">
- <config>
- <UDP
+ for REPL_ASYNC) where message bundling may improve performance.">
+ <config>
+ <UDP
singleton_name="udp-async"
mcast_port="${jboss.jgroups.udp_async.mcast_port:45689}"
mcast_addr="${jboss.partition.udpGroup:228.11.11.11}"
@@ -110,33 +110,33 @@
oob_thread_pool.max_threads="200"
oob_thread_pool.keep_alive_time="1000"
oob_thread_pool.queue_enabled="false"
- oob_thread_pool.rejection_policy="discard"/>
- <PING timeout="2000" num_initial_members="3"/>
- <MERGE2 max_interval="100000" min_interval="20000"/>
- <FD_SOCK/>
- <FD timeout="6000" max_tries="5" shun="true"/>
- <VERIFY_SUSPECT timeout="1500"/>
- <BARRIER/>
- <pbcast.NAKACK use_mcast_xmit="true" gc_lag="0"
+ oob_thread_pool.rejection_policy="discard"/>
+ <PING timeout="2000" num_initial_members="3"/>
+ <MERGE2 max_interval="100000" min_interval="20000"/>
+ <FD_SOCK/>
+ <FD timeout="6000" max_tries="5" shun="true"/>
+ <VERIFY_SUSPECT timeout="1500"/>
+ <BARRIER/>
+ <pbcast.NAKACK use_mcast_xmit="true" gc_lag="0"
retransmit_timeout="300,600,1200,2400,4800"
- discard_delivered_msgs="true"/>
- <UNICAST timeout="300,600,1200,2400,3600"/>
- <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
- max_bytes="400000"/>
- <VIEW_SYNC avg_send_interval="10000"/>
- <pbcast.GMS print_local_addr="true" join_timeout="3000"
+ discard_delivered_msgs="true"/>
+ <UNICAST timeout="300,600,1200,2400,3600"/>
+ <pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
+ max_bytes="400000"/>
+ <VIEW_SYNC avg_send_interval="10000"/>
+ <pbcast.GMS print_local_addr="true" join_timeout="3000"
shun="true"
view_bundling="true"
view_ack_collection_timeout="5000"
- resume_task_timeout="7500"/>
- <FC max_credits="2000000" min_threshold="0.10"
- ignore_synchronous_response="true"/>
- <FRAG2 frag_size="60000"/>
- <!-- pbcast.STREAMING_STATE_TRANSFER/ -->
- <pbcast.STATE_TRANSFER/>
- <pbcast.FLUSH timeout="0" start_flush_timeout="10000"/>
- </config>
- </stack> ]]>
+ resume_task_timeout="7500"/>
+ <FC max_credits="2000000" min_threshold="0.10"
+ ignore_synchronous_response="true"/>
+ <FRAG2 frag_size="60000"/>
+ <!-- pbcast.STREAMING_STATE_TRANSFER/ -->
+ <pbcast.STATE_TRANSFER/>
+ <pbcast.FLUSH timeout="0" start_flush_timeout="10000"/>
+ </config>
+ </stack> ]]>
</programlisting>
@@ -152,7 +152,7 @@
<itemizedlist>
<listitem>
<para>
- <literal>stats</literal> whether the protocol should gather runtime statistics on its operations that can be exposed via tools like the AS's administration console or the JGroups Probe utility. What, if any, statistics are gathered depends on the protocol. Default is <literal>true</literal>.
+ <literal>stats</literal> whether the protocol should gather runtime statistics on its operations that can be exposed via tools like the AS's JMX console or the JGroups Probe utility. What, if any, statistics are gathered depends on the protocol. Default is <literal>true</literal>.
</para>
</listitem>
</itemizedlist>
@@ -180,12 +180,12 @@
</note>
<section id="jgroups-transport-udp">
<title>UDP configuration</title>
- <para>UDP is the preferred protocol for JGroups. UDP uses multicast (or,
+ <para>UDP is the preferred transport protocol for JGroups. UDP uses multicast (or,
in an unusual configuration, multiple unicasts) to send and
receive messages. If you choose UDP as the transport protocol for your cluster service, you need
to configure it in the <literal>UDP</literal> sub-element in the JGroups
<literal>config</literal> element. Here is an example.</para>
-<programlisting><![CDATA[ <UDP
+<programlisting><![CDATA[ <UDP
singleton_name="udp-async"
mcast_port="${jboss.jgroups.udp_async.mcast_port:45689}"
mcast_addr="${jboss.partition.udpGroup:228.11.11.11}"
@@ -219,12 +219,12 @@
oob_thread_pool.max_threads="200"
oob_thread_pool.keep_alive_time="1000"
oob_thread_pool.queue_enabled="false"
- oob_thread_pool.rejection_policy="discard"/>]]>
+ oob_thread_pool.rejection_policy="discard"/>]]>
</programlisting>
<para>
- This JGroups configuration has a number of attributes available. First we look
+ JGroups transport configurations have a number of attributes available. First we look
at the attributes available to the <literal>UDP</literal> protocol, followed
by the attributes that are also used by the <literal>TCP</literal> and
<literal>TUNNEL</literal> transport protocols.
@@ -250,7 +250,7 @@
See <xref linkend="clustering-jgroups-isolation"/> for information about using
this configuration attribute to ensure that JGroups channels are properly
isolated from one another.
- If this attribute is omitted, the default value is <literal>228.8.8.8</literal>.
+ If this attribute is omitted, the default value is <literal>228.11.11.11</literal>.
</para>
</listitem>
<listitem>
@@ -258,7 +258,7 @@
to use for multicast communication with the group.
See <xref linkend="clustering-jgroups-isolation"/> for how to use this configuration attribute
to ensure JGroups channels are properly isolated from one another.
- If this attribute is omitted, the default is <literal>45566</literal>.</para>
+ If this attribute is omitted, the default is <literal>45688</literal>.</para>
</listitem>
<listitem>
<para>
@@ -910,7 +910,7 @@
</programlisting>
<para>
- In this example, a member becomes suspected when the neighbouring socket has been closed abnormally, in a process crash, for instance, since the operating system closes all sockets. However, if a host or switch crashes, the sockets will not be closed. <literal>FD</literal> will suspect the neighbour after thirty seconds (<literal>6000</literal> milliseconds). Note that if this example system were stopped in a breakpoint in the debugger, the node being debugged will be suspected once the <varname>timeout</varname> has elapsed.
+ In this example, a member becomes suspected when the neighbouring socket has been closed abnormally, in a process crash, for instance, since the operating system closes all sockets. However, if a host or switch crashes, the sockets will not be closed. <literal>FD</literal> will suspect the neighbour after sixty seconds (<literal>6000</literal> milliseconds). Note that if this example system were stopped in a breakpoint in the debugger, the node being debugged will be suspected once the <varname>timeout</varname> has elapsed.
</para>
<para>
A combination of <literal>FD</literal> and <literal>FD_SOCK</literal> provides a solid failure detection layer, which is why this technique is used across the JGroups configurations included with JBoss Application Server.
@@ -1151,7 +1151,7 @@
<literal>pbcast.STATE_TRANSFER</literal> sub-element under the JGroups <literal>Config</literal>
element. It does not have any configurable attribute. Here is an example configuration.</para>
<programlisting>
-<pbcast.STATE_TRANSFER down_thread="false" up_thread="false"/>
+<pbcast.STATE_TRANSFER/>
</programlisting>
</section>
@@ -1178,7 +1178,7 @@
received before the cluster triggers a garbage collection run. Set to <literal>0</literal> to disable garbage collection based on the bytes received.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">stability_delay</emphasis> specifies the maximum time period (in milliseconds) of a random delay introduced before a node sends its <literal>STABILITY</literal> message at the end of a garbage collection run. The delay gives other nodes concurrently running a <literal>STABLE</literal> task a change to send first. If used together with <literal>max_bytes</literal>, this attribute should be set to a small number.</para>
+ <para><emphasis role="bold">stability_delay</emphasis> specifies the maximum time period (in milliseconds) of a random delay introduced before a node sends its <literal>STABILITY</literal> message at the end of a garbage collection run. The delay gives other nodes concurrently running a <literal>STABLE</literal> task a chance to send first. If used together with <literal>max_bytes</literal>, this attribute should be set to a small number.</para>
</listitem>
</itemizedlist>
<note>
@@ -1189,17 +1189,16 @@
<section id="jgroups-other-merge">
<title>Merging (MERGE2)</title>
<para>
- When a network error occurs, the cluster might be partitioned into several different partitions. JGroups has a MERGE service that allows the coordinators in partitions to communicate with each other and form a single cluster back again. The flow control service is configured in the <literal>MERGE2</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration.
+ When a network error occurs, the cluster might be partitioned into several different partitions. JGroups has a MERGE service that allows the coordinators in partitions to communicate with each other and form a single cluster back again. The merging service is configured in the <literal>MERGE2</literal> sub-element under the JGroups <literal>Config</literal> element. Here is an example configuration.
</para>
<programlisting>
<MERGE2 max_interval="10000"
- min_interval="2000"
- down_thread="false" up_thread="false"/>
+ min_interval="2000"/>
</programlisting>
- <para>The configurable attributes in the <literal>FC</literal> element are as follows.</para>
+ <para>The configurable attributes in the <literal>MERGE2</literal> element are as follows.</para>
<itemizedlist>
<listitem>
<para><emphasis role="bold">max_interval</emphasis> specifies the maximum number of
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JMS.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JMS.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JMS.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -2,9 +2,14 @@
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
<chapter id="clustering-jms">
- <title>JBoss Messaging Clustering Notes</title>
-
- <section><title>Unique server peer id</title>
+ <title>JBoss Messaging Clustering Notes</title>
+
+ <para>
+ The most current information about using JBoss Messaging in a clustered environment is always available from the relevant <citetitle>JBoss Messaging User Guide</citetitle> at <ulink url="http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/">http://www.redhat.com/docs/en-US/JBoss_Enterprise_Application_Platform/</ulink>.
+ </para>
+
+
+ <!--<section><title>Unique server peer id</title>
<para>
JBoss Messaging clustering should work out of the box in the <emphasis>all</emphasis> configuration with no configuration changes. It is however crucial that every node is assigned a unique server id.
</para>
@@ -71,5 +76,5 @@
</para>
</section>
-</section>
+</section>-->
</chapter>
Modified: projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml
===================================================================
--- projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-12-11 06:59:34 UTC (rev 97718)
+++ projects/docs/enterprise/5.0/Administration_And_Configuration_Guide/en-US/Clustering_Guide_JNDI.xml 2009-12-11 08:21:38 UTC (rev 97719)
@@ -176,7 +176,7 @@
If different beans (even of the same type, but participating in
different clusters) use the same JNDI name, this means that each JNDI
server will have a logically different "target" bound under the same
- name. (JNDI on node 1 will have a binding for bean A and JNDI on node
+ name (JNDI on node 1 will have a binding for bean A and JNDI on node
2 will have a binding, under the same name, for bean B). Consequently,
if a client performs a HA-JNDI query for this name, the query will be
invoked on any JNDI server of the cluster and will return the locally
@@ -346,7 +346,7 @@
</section>
<section><title>How can I tell if things are being bound into HA-JNDI that shouldn't be?</title>
- <para>Go into the the jmx-console and execute the <literal>list</literal> operation on the <literal>jboss:service=JNDIView</literal> mbean. Towards the bottom of the results, the contents of the "HA-JNDI Namespace" are listed. Typically this will be empty; if any of your own deployments are shown there and you didn't explicitly bind them there, there's probably an improper jndi.properties file on the classpath. Please visit the following link for an example: <ulink url="http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104715">Problem with removing a Node from Cluster</ulink> </para>
+ <para>Go into the the jmx-console and execute the <literal>list</literal> operation on the <literal>jboss:service=JNDIView</literal> mbean. Towards the bottom of the results, the contents of the "HA-JNDI Namespace" are listed. Typically this will be empty; if any of your own deployments are shown there and you didn't explicitly bind them there, there's probably an improper jndi.properties file on the classpath. Please visit the following link for an example: <ulink url="http://www.jboss.com/index.html?module=bb&op=viewtopic&t=104715">Problem with removing a Node from Cluster</ulink>.</para>
</section>
@@ -364,7 +364,7 @@
the servers and ports).</para>
<programlisting>java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100</programlisting>
- <para>When initialising, the JNP client code will try to get in touch
+ <para>When initializing, the JNP client code will try to get in touch
with each server node from the list, one after the other, stopping as
soon as one server has been reached. It will then download the HA-JNDI
stub from this node.</para>
@@ -448,8 +448,7 @@
value of the AutoDiscoveryPort configured on the server side HA-JNDI service.</para>
</listitem>
<listitem>
- <para><literal>jnp.discoveryTTL</literal>: specifies the TTL (time-to-live) f
- or autodiscovery IP multicast packets. This value represents the number of
+ <para><literal>jnp.discoveryTTL</literal>: specifies the TTL (time-to-live) for autodiscovery IP multicast packets. This value represents the number of
network hops a multicast packet can be allowed to propagate before networking
equipment should drop the packet. Despite its name, it does not represent a unit of time.
</para>
@@ -568,7 +567,7 @@
<para>
Besides the above dependency injected services, the available configuration
- attributes for the HAJNDI bean are as follows:</para>
+ attributes for the HA-JNDI bean are as follows:</para>
<itemizedlist>
<listitem>
@@ -589,7 +588,7 @@
The default value is <literal>1100</literal>.</para>
</listitem>
<listitem>
- <para><emphasis role="bold">Backlog</emphasis> specifies the maximum
+ <para><emphasis role="bold">backlog</emphasis> specifies the maximum
queue length for incoming connection indications for the TCP server
socket on which the service listens for naming proxy download
requests from JNP clients. The default value is <literal>50</literal>.</para>
@@ -647,8 +646,8 @@
</listitem>
<listitem>
<para><emphasis role="bold">loadBalancePolicy</emphasis> specifies the
- class name of the LoadBalancePolicyimplementation that should be included
- in the client proxy. See <!--<xref linkend="clustering-intro-balancepolicy"/>-->
+ class name of the LoadBalancePolicy implementation that should be included
+ in the client proxy. See <xref linkend="clustering-intro.chapt"/>
the Introduction and Quick Start chapter for details.</para>
</listitem>
<listitem>
More information about the jboss-cvs-commits
mailing list