[jboss-cvs] JBossAS SVN: r82259 - projects/docs/community/5/Clustering_Guide/en-US.
jboss-cvs-commits at lists.jboss.org
jboss-cvs-commits at lists.jboss.org
Sat Dec 13 10:38:57 EST 2008
Author: bstansberry at jboss.com
Date: 2008-12-13 10:38:57 -0500 (Sat, 13 Dec 2008)
New Revision: 82259
Added:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HASingleton.xml
Modified:
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide.xml
projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HTTP.xml
Log:
Separate HASingleton from HTTP chapter
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide.xml 2008-12-13 15:38:29 UTC (rev 82258)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide.xml 2008-12-13 15:38:57 UTC (rev 82259)
@@ -8,6 +8,7 @@
<xi:include href="Clustering_Guide_EJBs.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Clustering_Guide_Entity_EJBs.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Clustering_Guide_HTTP.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+<xi:include href="Clustering_Guide_HASingleton.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
<xi:include href="Clustering_Guide_JMS.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <xi:include href="Clustering_Guide_JBoss_Cache_JGroups.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
+<xi:include href="Clustering_Guide_JBoss_Cache_JGroups.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
</book>
Added: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HASingleton.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HASingleton.xml (rev 0)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HASingleton.xml 2008-12-13 15:38:57 UTC (rev 82259)
@@ -0,0 +1,204 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.3//EN" "http://www.oasis-open.org/docbook/xml/4.3/docbookx.dtd">
+
+<chapter id="clustering-hasingleton">
+
+ <title>Clustered Singleton Services</title>
+
+ <para>A clustered singleton service (also known as an HA singleton) is a service that is deployed on multiple nodes in a cluster, but is providing its service on only one of the nodes. The node running the singleton service is typically called the master node. When the master fails or is shut down, another master is selected from the remaining nodes and the service is restarted on the new master. Thus, other than a brief interval when one master has stopped and another has yet to take over, the service is always being provided by one but only one node.
+ </para>
+ <figure id="master_node_fail.fig">
+ <title>Topology after the Master Node fails</title>
+ <mediaobject>
+ <imageobject>
+ <imagedata align="center" fileref="images/master_node_fail.png"/>
+ </imageobject>
+ </mediaobject>
+ </figure>
+
+ <section>
+ <title>Deployment Options</title>
+ <para>
+ The JBoss Application Server (AS) provides support for a number of strategies for helping you deploy clustered singleton services. In this section we will explore the different strategies. All of the strategies are built on top of the HAPartition service described in the introduction. They rely on the <literal>HAPartition</literal> to provide notifications when different nodes in the cluster start and stop; based on those notifications each node in the cluster can independently (but consistently) determine if it is now the master node and needs to begin providing a service.
+ </para>
+
+
+ <section><title>HASingletonDeployer service</title>
+ <para>
+ The simplest and most commonly used strategy for deploying an HA singleton is to take an ordinary deployment (war, ear, jar, whatever you would normally put in deploy) and deploy it in the <literal>$JBOSS_HOME/server/all/deploy-hasingleton</literal> directory instead of in <literal>deploy</literal>. The <literal>deploy-hasingleton</literal> directory does not lie under deploy or farm, so its contents are not automatically deployed when an AS instance starts. Instead, deploying the contents of this directory is the responsibility of a special service, the <literal>jboss.ha:service=HASingletonDeployer</literal> MBean (which itself is deployed via the deploy/deploy-hasingleton-service.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 being the master (typically at server shutdown) is to undeploy the contents of <lit!
eral>deploy-hasingleton</literal>.
+ </para>
+ <para>
+ So, by placing your deployments in <literal>deploy-hasingleton</literal> you know that they will be deployed only on the master node in the cluster. If the master node cleanly shuts down, they will be cleanly undeployed as part of shutdown. If the master node fails or is shut down, they will be deployed on whatever node takes over as master.
+ </para>
+ <para>Using deploy-hasingleton is very simple, but it does have two drawbacks:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>There is no hot-deployment feature for services in <literal>deploy-hasingleton</literal>. Redeploying a service that has been deployed to <literal>deploy-hasingleton</literal> requires a server restart.
+ </para>
+ </listitem>
+
+ <listitem>
+ <para>If the master node fails and another node takes over as master, your singleton service needs to go through the entire deployment process before it will be providing services. Depending on how complex the deployment of your service is and what sorts of startup activities it engages in, this could take a while, during which time the service is not being provided.
+ </para>
+ </listitem>
+
+ <!-- <listitem>
+ <para>
+ </para>
+ </listitem>-->
+ </itemizedlist>
+
+ </section>
+
+ <section><title>Mbean deployments using HASingletonController</title>
+ <para>
+ If your service is an Mbean (i.e., not a J2EE deployment like an ear or war or jar), you can deploy it along with a service called an HASingletonController in order to turn it into an HA singleton. It is the job of the HASingletonController to work with the HAPartition service to monitor the cluster and determine if it is now the master node for its service. If it determines it has become the master node, it invokes a method on your service telling it to begin providing service. If it determines it is no longer the master node, it invokes a method on your service telling it to stop providing service. Let's walk through an illustration.
+ </para>
+ <para>First, we have an MBean service that we want to make an HA singleton. The only thing special about it is it needs to expose in its MBean interface a method that can be called when it should begin providing service, and another that can be called when it should stop providing service:
+ </para>
+
+<programlisting><![CDATA[
+public class HASingletonExample
+implements HASingletonExampleMBean {
+
+private boolean isMasterNode = false;
+
+public void startSingleton() {
+isMasterNode = true;
+}
+.
+public boolean isMasterNode() {
+return isMasterNode;
+ }
+
+ public void stopSingleton() {
+ isMasterNode = false;
+ }
+} ]]>
+</programlisting>
+
+<para>
+ We used “startSingleton” and “stopSingleton” in the above example, but you could name the methods anything.
+</para>
+<para>
+ Next, we deploy our service, along with an HASingletonController to control it, most likely packaged in a .sar file, with the following <literal>META-INF/jboss-service.xml</literal>:
+</para>
+<programlisting><![CDATA[
+ <server>
+ <!-- This MBean is an example of a clustered singleton -->
+ <mbean code="org.jboss.ha.examples.HASingletonExample"
+ name=“jboss:service=HASingletonExample"/>
+
+ <!-- This HASingletonController manages the cluster Singleton -->
+ <mbean code="org.jboss.ha.singleton.HASingletonController"
+ name="jboss:service=ExampleHASingletonController">
+
+ <!-- Inject a ref to the HAPartition -->
+ <depends optional-attribute-name="ClusterPartition" proxy-type="attribute">
+ jboss:service=${jboss.partition.name:DefaultPartition}
+ </depends>
+ <!-- Inject a ref to the service being controlled -->
+ <depends optional-attribute-name="TargetName">
+ jboss:service=HASingletonExample
+ </depends>
+ <!-- Methods to invoke when become master / stop being master -->
+ <attribute name="TargetStartMethod">startSingleton</attribute>
+ <attribute name="TargetStopMethod">stopSingleton</attribute>
+ </mbean>
+</server> ]]>
+</programlisting>
+
+<para>Voila! A clustered singleton service.
+</para>
+<para>
+ The obvious downside to this approach is it only works for MBeans. Upsides are that the above example can be placed in <literal>deploy</literal> or <literal>farm</literal> and thus can be hot deployed and farmed deployed. Also, if our example service had complex, time-consuming startup requirements, those could potentially be implemented in create() or start() methods. JBoss will invoke create() and start() as soon as the service is deployed; it doesn't wait until the node becomes the master node. So, the service could be primed and ready to go, just waiting for the controller to implement startSingleton() at which point it can immediately provide service.
+</para>
+<para>
+ The jboss.ha:service=HASingletonDeployer service discussed above is itself an interesting example of using an HASingletonController. Here is its deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-service.xml</literal> file):
+</para>
+<programlisting><![CDATA[
+<mbean code="org.jboss.ha.singleton.HASingletonController"
+name="jboss.ha:service=HASingletonDeployer">
+ <depends optional-attribute-name="ClusterPartition" proxy-type="attribute">
+ jboss:service=${jboss.partition.name:DefaultPartition}
+ </depends>
+ <depends optional-attributeame="TargetName">
+ jboss.system:service=MainDeployer
+ </depends>
+ <attribute name="TargetStartMethod">deploy</attribute>
+ <attribute name="TargetStartMethodArgument">
+ ${jboss.server.home.url}/deploy-hasingleton
+ </attribute>
+ <attribute name="TargetStopMethod">undeploy</attribute>
+ <attribute name="TargetStopMethodArgument">
+ ${jboss.server.home.url}/deploy-hasingleton
+ </attribute>
+</mbean> ]]>
+</programlisting>
+
+<para>
+ A few interesting things here. First the service being controlled is the <literal>MainDeployer</literal> service, which is the core deployment service in JBoss. That is, it's a service that wasn't written with an intent that it be controlled by an <literal>HASingletonController</literal>. But it still works! Second, the target start and stop methods are “deploy” and “undeploy”. No requirement that they have particular names, or even that they logically have “start” and “stop” functionality. Here the functionality of the invoked methods is more like “do” and “undo”. Finally, note the “<literal>TargetStart(Stop)MethodArgument</literal>” attributes. Your singleton service's start/stop methods can take an argument, in this case the location of the directory the <literal>MainDeployer</literal> should deploy/undeploy.
+</para>
+
+
+ </section>
+
+
+ <section><title>HASingleton deployments using a Barrier</title>
+ <para>Services deployed normally inside deploy or farm that want to be started/stopped whenever the content of deploy-hasingleton gets deployed/undeployed, (i.e., whenever the current node becomes the master), need only specify a dependency on the Barrier mbean:
+ </para>
+<programlisting><![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>]]>
+</programlisting>
+
+<para>
+ The way it works is that a BarrierController is deployed along with the jboss.ha:service=HASingletonDeployer MBean and listens for JMX notifications from it. A BarrierController is a relatively 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 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 notifications are received. Thus, other services need only depend on the Barrier MBean using the usual <depends> tag, and they will be started and stopped in tandem with the Barrier. When the BarrierController is undeployed the Barrier is destroyed too.
+</para>
+
+<para> This provides an alternative to the deploy-hasingleton approach in that we can use farming to distribute the service, while content in deploy-hasingleton must be copied manually on all nodes.
+</para>
+
+<para>
+ On the other hand, the barrier-dependent service will be instantiated/created (i.e., any create() method invoked) on all nodes, but only started on the master node. This is different with the deploy-hasingleton approach that will only deploy (instantiate/create/start) the contents of the deploy-hasingleton directory on one of the nodes.
+</para>
+
+<para>So services depending on the barrier will need to make sure they do minimal or no work inside their create() step, rather they should use start() to do the work.
+</para>
+
+<note><title>Note</title>
+ <para>The Barrier controls the start/stop of dependent services, but not their destruction, which happens only when the <literal>BarrierController</literal> is itself destroyed/undeployed. Thus using the <literal>Barrier</literal> to control services that need to be "destroyed" as part of their normal “undeploy” operation (like, for example, an <literal>EJBContainer</literal>) will not have the desired effect.
+</para>
+</note>
+
+
+
+</section>
+</section>
+
+<section><title>Determining the master node</title>
+ <para>The various clustered singleton management strategies all depend on the fact that each node in the cluster can independently react to changes in cluster membership and correctly decide whether it is now the “master node”. How is this done?
+ </para>
+
+ <para>Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple. For each member of the cluster, the HAPartition mbean maintains an attribute called the CurrentView, which is basically an ordered list of the current members of the cluster. As nodes join and leave the cluster, JGroups ensures that each surviving member of the cluster gets an updated view. You can see the current view by going into the JMX console, and looking at the CurrentView attribute in the <literal>jboss:service=DefaultPartition</literal> mbean. Every member of the cluster will have the same view, with the members in the same order.
+ </para>
+
+ <para>Let's say, for example, that we have a 4 node cluster, nodes A through D, and the current view can be expressed as {A, B, C, D}. Generally speaking, the order of nodes in the view will reflect the order in which they joined the cluster (although this is not always the case, and should not be assumed to be the case.)
+ </para>
+
+ <para>
+ To further our example, let's say there is a singleton service (i.e., an <literal>HASingletonController</literal>) named Foo that's deployed around the cluster, except, for whatever reason, on B. The <literal>HAPartition</literal> service maintains across the cluster a registry of what services are deployed where, in view order. So, on every node in the cluster, the <literal>HAPartition</literal> service knows that the view with respect to the Foo service is {A, C, D} (no B).
+ </para>
+
+ <para>
+ Whenever there is a change in the cluster topology of the Foo service, the <literal>HAPartition</literal> service invokes a callback on Foo notifying it of the new topology. So, for example, when Foo started on D, the Foo service running on A, C and D all got callbacks telling them the new view for Foo was {A, C, D}. That callback gives each node enough information to independently decide if it is now the master. The Foo service on each node does this by checking if they are the first member of the view – if they are, they are the master; if not, they're not. Simple as that.
+ </para>
+
+ <para>
+ If A were to fail or shutdown, Foo on C and D would get a callback with a new view for Foo of {C, D}. C would then become the master. If A restarted, A, C and D would get a callback with a new view for Foo of {C, D, A}. C would remain the master – there's nothing magic about A that would cause it to become the master again just because it was before.
+ </para>
+
+</section>
+
+
+ </chapter>
+
Modified: projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HTTP.xml
===================================================================
--- projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HTTP.xml 2008-12-13 15:38:29 UTC (rev 82258)
+++ projects/docs/community/5/Clustering_Guide/en-US/Clustering_Guide_HTTP.xml 2008-12-13 15:38:57 UTC (rev 82259)
@@ -555,201 +555,6 @@
<programlisting><Valve className="org.jboss.web.tomcat.tc5.sso.ClusteredSingleSignOn" /></programlisting>
</section>
- <section><title>Clustered Singleton Services</title>
- <para>A clustered singleton service (also known as an HA singleton) is a service that is deployed on multiple nodes in a cluster, but is providing its service on only one of the nodes. The node running the singleton service is typically called the master node. When the master fails or is shut down, another master is selected from the remaining nodes and the service is restarted on the new master. Thus, other than a brief interval when one master has stopped and another has yet to take over, the service is always being provided by one but only one node.
- </para>
- <figure id="master_node_fail.fig">
- <title>Topology after the Master Node fails</title>
- <mediaobject>
- <imageobject>
- <imagedata align="center" fileref="images/master_node_fail.png"/>
- </imageobject>
- </mediaobject>
- </figure>
-
- <para>
- The JBoss Application Server (AS) provides support for a number of strategies for helping you deploy clustered singleton services. In this section we will explore the different strategies. All of the strategies are built on top of the HAPartition service described in the introduction. They rely on the <literal>HAPartition</literal> to provide notifications when different nodes in the cluster start and stop; based on those notifications each node in the cluster can independently (but consistently) determine if it is now the master node and needs to begin providing a service.
- </para>
-
-
- <section><title>HASingletonDeployer service</title>
- <para>
- The simplest and most commonly used strategy for deploying an HA singleton is to take an ordinary deployment (war, ear, jar, whatever you would normally put in deploy) and deploy it in the <literal>$JBOSS_HOME/server/all/deploy-hasingleton</literal> directory instead of in <literal>deploy</literal>. The <literal>deploy-hasingleton</literal> directory does not lie under deploy or farm, so its contents are not automatically deployed when an AS instance starts. Instead, deploying the contents of this directory is the responsibility of a special service, the <literal>jboss.ha:service=HASingletonDeployer</literal> MBean (which itself is deployed via the deploy/deploy-hasingleton-service.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 being the master (typically at server shutdown) is to undeploy the contents of <lit!
eral>deploy-hasingleton</literal>.
- </para>
- <para>
- So, by placing your deployments in <literal>deploy-hasingleton</literal> you know that they will be deployed only on the master node in the cluster. If the master node cleanly shuts down, they will be cleanly undeployed as part of shutdown. If the master node fails or is shut down, they will be deployed on whatever node takes over as master.
- </para>
- <para>Using deploy-hasingleton is very simple, but it does have two drawbacks:</para>
-
- <itemizedlist>
- <listitem>
- <para>There is no hot-deployment feature for services in <literal>deploy-hasingleton</literal>. Redeploying a service that has been deployed to <literal>deploy-hasingleton</literal> requires a server restart.
- </para>
- </listitem>
-
- <listitem>
- <para>If the master node fails and another node takes over as master, your singleton service needs to go through the entire deployment process before it will be providing services. Depending on how complex the deployment of your service is and what sorts of startup activities it engages in, this could take a while, during which time the service is not being provided.
- </para>
- </listitem>
-
- <!-- <listitem>
- <para>
- </para>
- </listitem>-->
- </itemizedlist>
-
- </section>
-
- <section><title>Mbean deployments using HASingletonController</title>
- <para>
- If your service is an Mbean (i.e., not a J2EE deployment like an ear or war or jar), you can deploy it along with a service called an HASingletonController in order to turn it into an HA singleton. It is the job of the HASingletonController to work with the HAPartition service to monitor the cluster and determine if it is now the master node for its service. If it determines it has become the master node, it invokes a method on your service telling it to begin providing service. If it determines it is no longer the master node, it invokes a method on your service telling it to stop providing service. Let's walk through an illustration.
- </para>
- <para>First, we have an MBean service that we want to make an HA singleton. The only thing special about it is it needs to expose in its MBean interface a method that can be called when it should begin providing service, and another that can be called when it should stop providing service:
- </para>
-
-<programlisting><![CDATA[
-public class HASingletonExample
-implements HASingletonExampleMBean {
-
-private boolean isMasterNode = false;
-
-public void startSingleton() {
-isMasterNode = true;
-}
-.
-public boolean isMasterNode() {
-return isMasterNode;
- }
-
- public void stopSingleton() {
- isMasterNode = false;
- }
-} ]]>
-</programlisting>
-
-<para>
- We used “startSingleton” and “stopSingleton” in the above example, but you could name the methods anything.
-</para>
-<para>
- Next, we deploy our service, along with an HASingletonController to control it, most likely packaged in a .sar file, with the following <literal>META-INF/jboss-service.xml</literal>:
-</para>
-<programlisting><![CDATA[
- <server>
- <!-- This MBean is an example of a clustered singleton -->
- <mbean code="org.jboss.ha.examples.HASingletonExample"
- name=“jboss:service=HASingletonExample"/>
-
- <!-- This HASingletonController manages the cluster Singleton -->
- <mbean code="org.jboss.ha.singleton.HASingletonController"
- name="jboss:service=ExampleHASingletonController">
-
- <!-- Inject a ref to the HAPartition -->
- <depends optional-attribute-name="ClusterPartition" proxy-type="attribute">
- jboss:service=${jboss.partition.name:DefaultPartition}
- </depends>
- <!-- Inject a ref to the service being controlled -->
- <depends optional-attribute-name="TargetName">
- jboss:service=HASingletonExample
- </depends>
- <!-- Methods to invoke when become master / stop being master -->
- <attribute name="TargetStartMethod">startSingleton</attribute>
- <attribute name="TargetStopMethod">stopSingleton</attribute>
- </mbean>
-</server> ]]>
-</programlisting>
-
-<para>Voila! A clustered singleton service.
-</para>
-<para>
- The obvious downside to this approach is it only works for MBeans. Upsides are that the above example can be placed in <literal>deploy</literal> or <literal>farm</literal> and thus can be hot deployed and farmed deployed. Also, if our example service had complex, time-consuming startup requirements, those could potentially be implemented in create() or start() methods. JBoss will invoke create() and start() as soon as the service is deployed; it doesn't wait until the node becomes the master node. So, the service could be primed and ready to go, just waiting for the controller to implement startSingleton() at which point it can immediately provide service.
-</para>
-<para>
- The jboss.ha:service=HASingletonDeployer service discussed above is itself an interesting example of using an HASingletonController. Here is its deployment descriptor (extracted from the <literal>deploy/deploy-hasingleton-service.xml</literal> file):
-</para>
-<programlisting><![CDATA[
-<mbean code="org.jboss.ha.singleton.HASingletonController"
-name="jboss.ha:service=HASingletonDeployer">
- <depends optional-attribute-name="ClusterPartition" proxy-type="attribute">
- jboss:service=${jboss.partition.name:DefaultPartition}
- </depends>
- <depends optional-attributeame="TargetName">
- jboss.system:service=MainDeployer
- </depends>
- <attribute name="TargetStartMethod">deploy</attribute>
- <attribute name="TargetStartMethodArgument">
- ${jboss.server.home.url}/deploy-hasingleton
- </attribute>
- <attribute name="TargetStopMethod">undeploy</attribute>
- <attribute name="TargetStopMethodArgument">
- ${jboss.server.home.url}/deploy-hasingleton
- </attribute>
-</mbean> ]]>
-</programlisting>
-
-<para>
- A few interesting things here. First the service being controlled is the <literal>MainDeployer</literal> service, which is the core deployment service in JBoss. That is, it's a service that wasn't written with an intent that it be controlled by an <literal>HASingletonController</literal>. But it still works! Second, the target start and stop methods are “deploy” and “undeploy”. No requirement that they have particular names, or even that they logically have “start” and “stop” functionality. Here the functionality of the invoked methods is more like “do” and “undo”. Finally, note the “<literal>TargetStart(Stop)MethodArgument</literal>” attributes. Your singleton service's start/stop methods can take an argument, in this case the location of the directory the <literal>MainDeployer</literal> should deploy/undeploy.
-</para>
-
-
- </section>
-
-
- <section><title>HASingleton deployments using a Barrier</title>
- <para>Services deployed normally inside deploy or farm that want to be started/stopped whenever the content of deploy-hasingleton gets deployed/undeployed, (i.e., whenever the current node becomes the master), need only specify a dependency on the Barrier mbean:
- </para>
-<programlisting><![CDATA[<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>]]>
-</programlisting>
-
-<para>
- The way it works is that a BarrierController is deployed along with the jboss.ha:service=HASingletonDeployer MBean and listens for JMX notifications from it. A BarrierController is a relatively 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 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 notifications are received. Thus, other services need only depend on the Barrier MBean using the usual <depends> tag, and they will be started and stopped in tandem with the Barrier. When the BarrierController is undeployed the Barrier is destroyed too.
-</para>
-
-<para> This provides an alternative to the deploy-hasingleton approach in that we can use farming to distribute the service, while content in deploy-hasingleton must be copied manually on all nodes.
-</para>
-
-<para>
- On the other hand, the barrier-dependent service will be instantiated/created (i.e., any create() method invoked) on all nodes, but only started on the master node. This is different with the deploy-hasingleton approach that will only deploy (instantiate/create/start) the contents of the deploy-hasingleton directory on one of the nodes.
-</para>
-
-<para>So services depending on the barrier will need to make sure they do minimal or no work inside their create() step, rather they should use start() to do the work.
-</para>
-
-<note><title>Note</title>
- <para>The Barrier controls the start/stop of dependent services, but not their destruction, which happens only when the <literal>BarrierController</literal> is itself destroyed/undeployed. Thus using the <literal>Barrier</literal> to control services that need to be "destroyed" as part of their normal “undeploy” operation (like, for example, an <literal>EJBContainer</literal>) will not have the desired effect.
-</para>
-</note>
-
-
-
-</section>
-
-
-<section><title>Determining the master node</title>
- <para>The various clustered singleton management strategies all depend on the fact that each node in the cluster can independently react to changes in cluster membership and correctly decide whether it is now the “master node”. How is this done?
- </para>
-
- <para>Prior to JBoss AS 4.2.0, the methodology for this was fixed and simple. For each member of the cluster, the HAPartition mbean maintains an attribute called the CurrentView, which is basically an ordered list of the current members of the cluster. As nodes join and leave the cluster, JGroups ensures that each surviving member of the cluster gets an updated view. You can see the current view by going into the JMX console, and looking at the CurrentView attribute in the <literal>jboss:service=DefaultPartition</literal> mbean. Every member of the cluster will have the same view, with the members in the same order.
- </para>
-
- <para>Let's say, for example, that we have a 4 node cluster, nodes A through D, and the current view can be expressed as {A, B, C, D}. Generally speaking, the order of nodes in the view will reflect the order in which they joined the cluster (although this is not always the case, and should not be assumed to be the case.)
- </para>
-
- <para>
- To further our example, let's say there is a singleton service (i.e., an <literal>HASingletonController</literal>) named Foo that's deployed around the cluster, except, for whatever reason, on B. The <literal>HAPartition</literal> service maintains across the cluster a registry of what services are deployed where, in view order. So, on every node in the cluster, the <literal>HAPartition</literal> service knows that the view with respect to the Foo service is {A, C, D} (no B).
- </para>
-
- <para>
- Whenever there is a change in the cluster topology of the Foo service, the <literal>HAPartition</literal> service invokes a callback on Foo notifying it of the new topology. So, for example, when Foo started on D, the Foo service running on A, C and D all got callbacks telling them the new view for Foo was {A, C, D}. That callback gives each node enough information to independently decide if it is now the master. The Foo service on each node does this by checking if they are the first member of the view – if they are, they are the master; if not, they're not. Simple as that.
- </para>
-
- <para>
- If A were to fail or shutdown, Foo on C and D would get a callback with a new view for Foo of {C, D}. C would then become the master. If A restarted, A, C and D would get a callback with a new view for Foo of {C, D, A}. C would remain the master – there's nothing magic about A that would cause it to become the master again just because it was before.
- </para>
-
-</section>
-
- </section>
-
</chapter>
More information about the jboss-cvs-commits
mailing list