[jboss-cvs] JBossAS SVN: r102989 - projects/docs/community/4/Clustering_Guide/en-US.

[jboss-cvs-commits at lists.jboss.org]

Author: misty at redhat.com
Date: 2010-03-25 19:40:04 -0400 (Thu, 25 Mar 2010)
New Revision: 102989

Modified:
   projects/docs/community/4/Clustering_Guide/en-US/Clustering_Guide.xml
Log:
Made changes to address JBDOCS-269


Modified: projects/docs/community/4/Clustering_Guide/en-US/Clustering_Guide.xml
===================================================================
--- projects/docs/community/4/Clustering_Guide/en-US/Clustering_Guide.xml	2010-03-25 21:49:17 UTC (rev 102988)
+++ projects/docs/community/4/Clustering_Guide/en-US/Clustering_Guide.xml	2010-03-25 23:40:04 UTC (rev 102989)
@@ -192,7 +192,7 @@
           <itemizedlist>
             <listitem>
 		    <para>
-			    Round-Robin (<literal>org.jboss.ha.framework.interfaces.RoundRobin</literal>): each call is dispatched to a new node, proceeding sequentially through the list of nodes. The first target node is randomly selected from the list.
+			    Round-Robin (<literal>org.jboss.ha.framework.interfaces.RoundRobin</literal>): each call is dispatched to a new node, proceeding sequentially through the list of nodes. Only the first target node is randomly selected from the list.
 		    </para>
             </listitem>
 	    
@@ -203,20 +203,20 @@
             </listitem>
             <listitem>
               <para>
-		      First Available (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal>): one of the available target nodes is elected as the main target and is thereafter used for every call; this elected member is randomly chosen from the list of members in the cluster. When the list of target nodes changes (because a node starts or dies), the policy will choose a new target node unless the currently elected node is still available. Each client-side stub elects its own target node independently of the other stubs, so if a particular client downloads two stubs for the same target service (e.g., an EJB), each stub will independently pick its target.  This is an example of a policy that provides “session affinity” or “sticky sessions”, since the target node does not change once established.
+		      First Available (<literal>org.jboss.ha.framework.interfaces.FirstAvailable</literal>): one of the available target nodes is elected (at random) as the main target. It is used for every call unless it becomes unavailable, at which time the process starts over. Regardless of status changes on other nodes, the policy will continue using the currently-chosen node as long as it is functioning correctly. Each client-side stub elects its own target node independently of the other stubs, so if a particular client downloads two stubs for the same target service (e.g., an EJB), each stub independently chooses its target.  This is an example of a policy that provides “session affinity” or “sticky sessions”, since the target node does not change once established. The difference between <systemitem>firstAvailable</systemitem> and <systemitem>firstAvailableIdenticalAllProxies</systemitem> is the level at which the choice of target node is made. For <systemitem>firstAvaila!
 ble</systemitem>, the decision is made at the stub level.
 	      </para>
             </listitem>
 	    
     
             <listitem>
 	    <para>
-		    First Available Identical All Proxies (<literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal>): has the same behaviour as the "First Available" policy but the elected target node is shared by all stubs in the same client-side VM that are associated with the same target service. So if a particular client downloads two stubs for the same target service (e.g. an EJB), each stub will use the same target.
+		    First Available Identical All Proxies (<literal>org.jboss.ha.framework.interfaces.FirstAvailableIdenticalAllProxies</literal>): has the same behaviour as the "First Available" policy, except for the level at which the choice of target node is made. The elected target node is shared by all stubs in the same client-side VM which are associated with the same target service. If a particular client downloads two stubs for the same target service (e.g. an EJB), each stub will use the same target.
     </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  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.
 	</para>
 </section>
 	<section><title>External load balancer architecture</title>