1.4.3. Farming Deployment

1.4.3. Farming Deployment

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 all/farm/ directory of any of the cluster members and the application will be automatically duplicated across all nodes in the same cluster. If node joins the cluster later, it will pull in all farm deployed applications in the cluster and deploy them locally at start-up time. If you delete the application from one of the running cluster server node's farm/ folder, the application will be undeployed locally and then removed from all other cluster server nodes farm folder (triggers undeployment.) You should manually delete the application from the farm folder of any server node not currently connected to the cluster.

Note

Currently, due to an implementation weakness, the farm deployment service only works for 1) archives located in the farm/ directory of the first node to join the cluster or 2) hot-deployed archives. If you first put a new application in the farm/ directory and then start the server to have it join an already running cluster, the application will not be pushed across the cluster or deployed. This is because the farm service does not know whether the application really represents a new deployment or represents an old deployment that was removed from the rest of the cluster while the newly starting node was off-line. We are working to resolve this issue.

Note

You can only put zipped archive files, not exploded directories, in the farm directory. If exploded directories are placed in farm the directory contents will be replicated around the cluster piecemeal, and it is very likely that remote nodes will begin trying to deploy things before all the pieces have arrived, leading to deployment failure.

Note

Farmed deployment is not atomic. A problem deploying, undeploying or redeploying an application on one node in the cluster will not prevent the deployment, undeployment or redeployment being done on the other nodes. There is no rollback capability. Deployment is also not staggered; it is quite likely, for example, that a redeployment will happen on all nodes in the cluster simultaneously, briefly leaving no nodes in the cluster providing service.

Farming is enabled by default in the all configuration in JBoss AS distributions, so you will not have to set it up yourself. The farm-service.xml configuration file is located in the deploy/deploy.last directory. If you want to enable farming in a custom configuration, simply copy the farm-service.xml file and copy it to the JBoss deploy directory $JBOSS_HOME/server/your_own_config/deploy/deploy.last. Make sure that your custom configuration has clustering enabled.

After deploying farm-service.xml you are ready to rumble. The required FarmMemberService MBean attributes for configuring a farm are listed below.

<?xml version="1.0" encoding="UTF-8"?>    
<server>        
        
    <mbean code="org.jboss.ha.framework.server.FarmMemberService"     
            name="jboss:service=FarmMember,partition=DefaultPartition">     
        ...      
	
	<depends optional-attribute-name="ClusterPartition" 
	proxy-type="attribute">
		jboss:service=${jboss.partition.name:DefaultPartition}
		</depends>     
		<attribute name="ScanPeriod">5000</attribute>      
		<attribute name="URLs">farm/</attribute>     
	...
	</mbean>       
</server>
            

The farming service is an extension of the URLDeploymentScanner, which scans for hot deployments in the deploy/ directory. So, you can use all the attributes defined in the URLDeploymentScanner MBean in the FarmMemberService MBean. In fact, the URLs and ScanPeriod attributes listed above are inherited from the URLDeploymentScanner MBean.