[jboss-cvs] JBossAS SVN: r83675 - projects/docs/community/5/Clustering_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Fri Jan 30 08:16:50 EST 2009
Author: bstansberry at jboss.com
Date: 2009-01-30 08:16:50 -0500 (Fri, 30 Jan 2009)
New Revision: 83675
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml
Log:
[JBAS-6358] Some HAPartition updates
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml 2009-01-30 12:12:24 UTC (rev 83674)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_Introduction.xml 2009-01-30 13:16:50 UTC (rev 83675)
@@ -409,15 +409,15 @@
</enterprise-beans>
</jboss> </programlisting>
- <para>See <xref linkend="clustering-session"/>for more advanced
+ <para>See <xref linkend="clustering-session"/> for more advanced
configuration options.</para>
</section>
<section id="clustering-quickstart-ejb3entities">
- <title>JPA Entity Clustering Quick Start</title>
+ <title>Entity Clustering Quick Start</title>
<para>One of the big improvements in the clustering area in JBoss AS 5
- is the use of the new Hibernate/JBoss Cache integration for second
- level caching that was introduced in Hibernate 3.3. In the JPA/Hibernate
+ is the use of the new Hibernate/JBoss Cache integration for second level
+ entity caching that was introduced in Hibernate 3.3. In the JPA/Hibernate
context, a second level cache refers to a cache whose contents are
retained beyond the scope of a transaction. A second level cache
<emphasis>may</emphasis> improve performance by reducing the number
@@ -471,7 +471,7 @@
public class Account implements Serializable]]>
</programlisting>
- <para>See <xref linkend="clustering-entity"/>for more advanced
+ <para>See <xref linkend="clustering-entity"/> for more advanced
configuration options and details on how to configure the same
thing for a non-JPA Hibernate application.</para>
</section>
@@ -481,7 +481,10 @@
<section id="clustering-concepts">
<title>Clustering Concepts</title>
<para>
- In the next section, we discuss basic concepts behind JBoss's clustering services. It is important that you understand these concepts before reading the rest of the chapter. Clustering configurations for specific types of applications are covered after this section.
+ In the next section, we discuss basic concepts behind JBoss's clustering
+ services. It is helpful that you understand these concepts before reading
+ the rest of the Clustering Guide. Clustering configurations for specific
+ types of applications are covered beginning with the next chapter.
</para>
<section id="clustering-concepts-def">
@@ -585,7 +588,7 @@
and how to failover the request if the target node not available.
As part of handling each service request, if the cluster topology has
changed the server node updates the proxy with the latest changes
- in the cluster. For instance, if a node drops out of the cluster, each of
+ in the cluster. For instance, if a node drops out of the cluster, each
proxy is updated with the new topology the next time it connects to any
active node in the cluster. All the manipulations done by the proxy's
clustering logic are transparent to the client application. The client-side
@@ -609,7 +612,7 @@
<para>
Other JBoss services, in particular the HTTP-based services, do not
require the client to download anything. The client (e.g., a web browser)
- sends in requests and receives responses directly over the wire according
+ sends in requests and receives responses directly over the wire using
to certain communication protocols (e.g., the HTTP protocol). In this
case, an external load balancer is required to process all requests and
dispatch them to server nodes in the cluster. The client only needs to know
@@ -684,7 +687,7 @@
<section><title>External load balancer architecture</title>
<para>
-As noted above, an external load balancer provides its own load balancing capabilities. What capabilities are supported depends on the provider of the load balancer. The only JBoss requirement is that the load balancer support “session affinitiy” (a.k.a. “sticky sessions”). With session affinitiy enabled, once the load balancer routes a request from a client to node A and the server initiates a session, all future requests associated with that session must be routed to node A, so long as node A is available.
+As noted above, an external load balancer provides its own load balancing capabilities. What capabilities are supported depends on the provider of the load balancer. The only JBoss requirement is that the load balancer support “session affinity” (a.k.a. “sticky sessions”). With session affinitiy enabled, once the load balancer routes a request from a client to node A and the server initiates a session, all future requests associated with that session must be routed to node A, so long as node A is available.
</para>
@@ -704,7 +707,7 @@
<title>The JBoss AS clustering architecture</title>
<mediaobject>
<imageobject>
- <imagedata align="center" fileref="images/clustering-as-arch.png"/>
+ <imagedata align="center" fileref="images/clustering-as-arch.png" />
</imageobject>
</mediaobject>
</figure>
@@ -728,6 +731,19 @@
of clustered web session state. See <xref linkend="clustering-blocks-jbc"/>
for more on how JBoss AS uses JBoss Cache and POJO Cache.</para>
+ <para><emphasis role="bold">HAPartition</emphasis> is an adapter on top
+ of a JGroups channel that allows multiple services to use the channel.
+ HAPartition also supports a distributed registry of which HAPartition-based
+ services are running on which cluster members. It provides notifications to
+ interested listeners when the cluster membership changes or the clustered
+ service registry changes. See <xref linkend="clustering-hapartition"/> for
+ more details on HAPartition.</para>
+
+ <para>The other higher level clustering services make use of JBoss Cache
+ or HAPartition, or, in the case of HA-JNDI, both. The exception to this
+ is JBoss Messaging's clustering features, which interact with JGroups
+ directly.</para>
+
<section id="clustering-blocks-jgroups">
<title>Group Communication with JGroups</title>
<para></para>
@@ -757,6 +773,7 @@
of the clustering services we'll be discussing in the rest of this
guide, including smart client-side clustered proxies, EJB 2 SFSB
replication and entity cache management, farming, HA-JNDI and HA singletons.
+ Custom services can also make use of HAPartition.
</para>
@@ -819,13 +836,92 @@
<para>You can view the current cluster information by pointing your browser to the JMX console of any
JBoss instance in the cluster (i.e., <literal>http://hostname:8080/jmx-console/</literal>) and then
- clicking on the <literal>jboss:service=DefaultPartition</literal> MBean (change the MBean name to reflect your partitionr name if you use the -g startup switch). A list of IP addresses for the current cluster members is shown in the CurrentView field.</para>
+ clicking on the <literal>jboss:service=HAPartition,partition=DefaultPartition</literal> MBean (change the MBean name to reflect your partitionr name if you use the -g startup switch). A list of IP addresses for the current cluster members is shown in the CurrentView field.</para>
<note><title>Note</title>
<para>
While it is technically possible to put a JBoss server instance into multiple HAPartitions at the same time, this practice is generally not recommended, as it increases management complexity.
</para>
</note>
+
+ <section id="clustering-hapartition-drm">
+ <title>DistributedReplicantManager Service</title>
+ <para>
+ The <literal>DistributedReplicantManager</literal> (DRM) service is a component
+ of the HAPartition service made available to HAPartition
+ users via the <literal>HAPartition.getDistributedReplicantManager()</literal>
+ method. Generally speaking, JBoss AS users will not directly make
+ use of the DRM; we discuss it here as an aid to those who want a
+ deeper understanding of how AS clustering internals work.</para>
+ <para>
+ The DRM is a distributed registry that allows HAPartition users to
+ register objects under a given key, making available to callersthe
+ set of objects registered under that key by the various members of t
+ he cluster. The DRM also provides a notification mechanism so interested
+ listeners can be notified when the contents of the registry changes.
+ </para>
+ <para>There are two main usages for the DRM in JBoss AS:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para><emphasis role="bold">Clustered Smart Proxies</emphasis></para>
+ <para>Here the keys are the names of the various services that need a
+ clustered smart proxy (see <xref linkend="clustering-concepts-arch-proxy"/>,
+ e.g. the name of a clustered EJB. The value object each node stores in
+ the DRM is known as a "target". It's something a smart proxy's transport
+ layer can use to contact the node (e.g. an RMI stub, an HTTP URL or a JBoss Remoting
+ <literal>InvokerLocator</literal>). The factory that builds clustered smart
+ proxies accesses the DRM to get the set of "targets" that should be
+ injected into the proxy to allow it to communicate with all the
+ nodes in a cluster.</para>
+ </listitem>
+ <listitem>
+ <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 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
+ service.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>In both cases, the key under which objects are registered identifies
+ a particular clustered service. It is useful to understand that every
+ node in a cluster doesn't have to register an object under every key.
+ Only services that are deployed on a particular node will register
+ 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>
+ </section>
+
+ <section id="clustering-hapartition-distributedstate">
+ <title>DistributedState Service</title>
+ <para>
+ The <literal>DistributedState</literal> service is a legacy component
+ of the HAPartition service made available to HAPartition
+ users via the <literal>HAPartition.getDistributedState()</literal>
+ method. This service provides coordinated management of arbitary
+ application state around the cluster. 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>
+ <para>In JBoss 5 the <literal>DistributedState</literal> service actually
+ delegates to an underlying JBoss Cache instance.</para>
+ </section>
+
+ <section id="clustering-hapartition-customsvcs">
+ <title>Custom Use of HAPartition</title>
+
+ <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.HAServiceImpl</literal>
+ base class, or the <literal>org.jboss.ha.jxm.HAServiceMBeanSupport</literal>
+ class if JMX registration and notification support are desired.
+ </para>
+
+ </section>
</section>
@@ -880,15 +976,15 @@
Services that need a cache ask the cache manager for the cache by
name; the cache manager creates the cache (if not already created)
and returns it. The cache manager keeps a reference to each cache
- it has created, so all services that request the same cache name
- will share the same cache. When a service is done with the cache,
+ it has created, so all services that request the same cache configuration
+ name will share the same cache. When a service is done with the cache,
it releases it to the cache manager. The cache manager keeps track
of how many services are using each cache, and will stop and destroy
the cache when all services have released it.</para>
<section id="clustering-blocks-jbc-cachemanager-stdconfigs">
<title>Standard Cache Configurations</title>
- <para>The following standard configuration ship with JBoss AS 5.
+ <para>The following standard JBoss Cache configurations ship with JBoss AS 5.
You can add others to suit your needs, or edit these configurations
to adjust cache behavior. Additions or changes are done by editing
the <literal>deploy/cluster/jboss-cache-manager.sar/META-INF/jboss-cache-manager-jboss-beans.xml</literal>
@@ -958,20 +1054,20 @@
<para><emphasis role="bold">local-query</emphasis></para>
<para>A config appropriate for JPA/Hibernate query result caching.
Does not replicate query results. DO NOT store the timestamp data
- Hibernate uses to verify query result validity in this cache.</para>
+ 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.
Replicates query results. DO NOT store the timestamp data
- Hibernate uses to verify query result validity in this cache.</para>
+ 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
- of JPA/Hibernate query result caching. A clustered timestamp cache
+ 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>
</listitem>
@@ -1087,6 +1183,12 @@
<section id="clustering-intro-farm">
<title>Farming Deployment</title>
+
+ <para>The Farm Service previously available in JBoss 4.x is not available
+ in JBoss 5.0 as it was incompatible with the new Profile Service at
+ the core of the AS. A new Profile Service-based replacement for the
+ Farm Service will be added in a future release.</para>
+<!--
<para>The easiest way to deploy an application into the cluster is to use the farming service. That is
to hot-deploy the application archive file (e.g., the EAR, WAR or SAR file) in the
<code>all/farm/</code> directory of any of the cluster members and the application will be automatically
@@ -1151,9 +1253,10 @@
<literal>FarmMemberService</literal> MBean. In fact, the <literal>URLs</literal> and
<literal>ScanPeriod</literal> attributes listed above are inherited from the
<literal>URLDeploymentScanner</literal> MBean.</para>
+-->
</section>
-
+ <!--
<section id="clustering-intro-state">
<title>Distributed state replication services</title>
<para>In a clustered server environment, distributed state management is a key service the cluster must
@@ -1178,6 +1281,6 @@
</itemizedlist>
</section>
-
+ -->
</chapter>
More information about the jboss-cvs-commits
mailing list