This section addresses the usual case: a cluster of three machines, each of which has, for example, an HAPartition deployed alongside JBoss Cache for web session clustering. The HAPartition channels should not communicate with the JBoss Cache channels. Ensuring proper isolation of these channels is straightforward, and is usually handled by the application server without any alterations on the part of the user.
To isolate channels for different services from each other on the same set of application server instances, each channel must have its own group name. The configurations that are shipped with JBoss Enterprise Web Platform ensure that this is the case. However, if you create a custom service that uses JGroups directly, you must use a unique group name. If you create a custom JBoss Cache configuration, ensure that you provide a unique value in the
clusterName configuration property.
JGroups uses shared transport by default, so it is common for multiple channels to use the same transport protocol and its sockets. This makes configuration easier, which is one of the main benefits of the shared transport. However, if you decide to create your own custom JGroups protocol stack configuration, be sure to configure its transport protocols with a multicast port that is different from the ports used in other protocol stacks.
The group name for a JGroups channel is configured via the service that starts the channel. For all the standard clustered services, we make it easy for you to create unique groups names by simply using the
-g (or --partition) switch when starting the server:
./run.sh -g QAPartition -b 192.168.1.100 -c production
This switch sets the
jboss.partition.name system property, which is used as a component in the configuration of the group name in all the standard clustering configuration files. For example,
<property name="clusterName">${jboss.partition.name:DefaultPartition}-SFSBCache</property>