deploy-hasingleton Directory
Since JBoss 3.2.4, server configuration "all" offers a deployment directory that contains services that are deployed on exactly one node in the cluster.
This directory is parallel to the deploy and farm deployment directories. Its lifecycle is controlled by the jboss.ha:service=HASingletonDeployer MBean service. It is declared in deploy-hasingleton-service.xml located under deploy.
The deploy-hasingleton directory contains services such as HAJMS, which is designed to run the JMS server on a single node in a clustered environment.
If the node where the singleton services are currently deployed fails, they will be automatically redeployed on another node in the cluster if one is available.
It's worth noting that JBoss Application Server can be configured with several singleton deploy folders, in similar fashion to URLDeploymentScanner where different deploy URLs can be defined. To do so, you have to duplicate jboss.ha:service=HASingletonDeployer MBean service changing the MBean service name, and also TargetStartMethodArgument and TargetStopMethodArgument attributes which enable you to have another HASingletonDeployer managing a different directory. For example:
<mbean code="org.jboss.ha.singleton.HASingletonController"
name="jboss.ha:service=HASingletonDeployer">
<depends>jboss:service=${jboss.partition.name:DefaultPartition}</depends>
<depends optional-attribute-name="TargetName">jboss.system:service=MainDeployer</depends>
<attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
<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>
<mbean code="org.jboss.ha.singleton.HASingletonController"
name="jboss.ha:service=HASingletonDeployer2">
<depends>jboss:service=${jboss.partition.name:DefaultPartition}</depends>
<depends optional-attribute-name="TargetName">jboss.system:service=MainDeployer</depends>
<attribute name="PartitionName">${jboss.partition.name:DefaultPartition}</attribute>
<attribute name="TargetStartMethod">deploy</attribute>
<attribute name="TargetStartMethodArgument">${jboss.server.home.url}/deploy-hasingleton2</attribute>
<attribute name="TargetStopMethod">undeploy</attribute>
<attribute name="TargetStopMethodArgument">${jboss.server.home.url}/deploy-hasingleton2</attribute>
</mbean>
HASingleton Deployments Using a Barrier
NOTE: The following is only available in JBoss 3.2.8/4.0.4 and later.
Services deployed normally inside ./deploy or ./farm that want to be started/stopped whenever the content of ./deploy-hasingleton/ gets deployed/undeployed, or else, whenever the current node becomes the master, need only specify a dependency on the Barrier mbean:
<depends>jboss.ha:service=HASingletonDeployer,type=Barrier</depends>
The way it works is that a BarrierController is deployed together with HASingletonController and listens for notifications from it. Based on those notifications it starts/stops a Barrier mbean, which will in turn start/stop any dependent service.
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.
On the other hand, the farmed service will be instantiated/created 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.
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.
Please Note: the Barrier controls the start/stop of dependend services, but not their destruction (this happens only when the BarrierController is itself destroyed/undeployed). Thus using the Barrier to control services that need to be "destroyed" as part of the normal Barrier operation will not have the desired effect. For example, EJB2 bean containers do most of their work in the create/destroy phase, so EJB2 beans cannot be deployed as HA singletons with this method. This is not the case with EJB3 beans though. Please see DeployingEJB3TimersInCluster for detailed information and an example on how to deploy an EJB3 as an HA singleton using the Barrier method.
Related notes
Comments