The easiest way to deploy an application into the cluster is to use the farming service. Using the farming service, you can deploy an application (e.g. EAR, WAR, or SAR; either an archive file or in exploded form) to the
all/farm/ directory of any cluster member and the application will be automatically duplicate across all nodes in the same cluster. If a 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 a running clustered server node's
farm/ directory, the application will be undeployed locally and then removed from all other clustered server nodes'
farm/ directories (triggering undeployment).
Farming is enabled by default in the
all configuration in JBoss Enterprise Application Platform and thus requires no manual setup. The required
timestamps-jboss-beans.xml configuration files are located in the
deploy/cluster directory. If you want to enable farming in a custom configuration, simply copy these files to the corresponding JBoss deploy directory
<JBOSS_HOME>/server/<PROFILE>/deploy/cluster. Make sure that your custom configuration has clustering enabled.
While there is little need to customize the farming service, it can be customized via the
FarmProfileRepositoryClusteringHandler bean, whose properties and default values are listed below:
<property name="partition"><inject bean="HAPartition"/></property>
<property name="lockTimeout">60000</property><!-- 1 minute -->
<property name="methodCallTimeout">60000</property><!-- 1 minute -->
<property name="synchronizationPolicy"><inject bean="FarmProfileSynchronizationPolicy"/></property>
partition is a required attribute to inject the HAPartition service that the farm service uses for intra-cluster communication.
profile[Domain|Server|Name] are all used to identify the server profile for which this handler is intended.
immutable indicates whether or not this handler allows a node to push content changes to the cluster. A value of
true is equivalent to setting
lockTimeout defines the number of milliseconds to wait for cluster-wide lock acquisition.
methodCallTimeout defines the number of milliseconds to wait for invocations on remote cluster nodes.
synchronizationPolicy decides how to handle content additions, reincarnations, updates, or removals from nodes attempting to join the cluster or from cluster merges. The policy is consulted on the "authoritative" node, i.e. the master node for the service on the cluster. Reincarnation refers to the phenomenon where a newly started node may contain an application in its
farm/ directory that was previously removed by the farming service but might still exist on the starting node if it was not running when the removal took place. The default synchronization policy is defined as follows:
<property name="removalTrackingTime">2592000000</property><!-- 30 days -->
<property name="timestampService"><inject bean="TimestampDiscrepancyService"/></property>
allow[Join|Merge][Additions|Reincarnations|Updates|Removals] define fixed responses to requests to allow additions, reincarnations, updates, or removals from joined or merged nodes.
developerMode enables a lenient synchronization policy that allows all changes. Enabling developer mode is equivalent to setting each of the above properties to
true and is intended for development environments.
removalTrackingTime defines the number of milliseconds for which this policy should remembered removed items, for use in detecting reincarnations.
timestampService estimates and tracks discrepancies in system clocks for current and past members of the cluster. Default implementation is defined in