28.6.2. Isolating JGroups Channels

Within JBoss Enterprise Application Platform, there are a number of services that independently create JGroups channels — possibly multiple different JBoss Cache services (used for HttpSession replication, EJB3 stateful session bean replication and EJB3 entity replication), two JBoss Messaging channels, and HAPartition, the general purpose clustering service that underlies most other JBossHA services.
It is critical that these channels only communicate with their intended peers; not with the channels used by other services and not with channels for the same service opened on machines not meant to be part of the group. Nodes improperly communicating with each other is one of the most common issues users have with JBoss Enterprise Application Platform clustering.
Whom a JGroups channel will communicate with is defined by its group name and, for UDP-based channels, its multicast address and port. Isolating a JGroups channel means ensuring that different channels use different values for the group name, the multicast address and, in some cases, the multicast port.

28.6.2.1. Isolating Sets of JBoss Enterprise Application Platform Instances from Each Other

This section addresses the issue of having multiple independent clusters running within the same environment. For example, you might have a production cluster, a staging cluster, and a QA cluster, or multiple clusters in a QA test lab or development team environment.
To isolate JGroups clusters from other clusters on the network, you must:
  • Make sure the channels in the various clusters use different group names. This can be controlled with the command line arguments used to start JBoss Enterprise Application Platform; see Section 28.6.2.2.1, “Changing the Group Name” for more information.
  • Make sure the channels in the various clusters use different multicast addresses. This is also easy to control with the command line arguments used to start JBoss.
  • If you are not running on Linux, Windows, Solaris or HP-UX, you may also need to ensure that the channels in each cluster use different multicast ports. This is more difficult than using different group names, although it can still be controlled from the command line. See Section 28.6.2.2.3, “Changing the Multicast Port”. Note that using different ports should not be necessary if your servers are running on Linux, Windows, Solaris or HP-UX.