28.6.2.2.3. Changing the Multicast Port

On some operating systems (Mac OS X for example), using different -g and -u values is not sufficient to isolate clusters; the channels running in the different clusters must also use different multicast ports. Unfortunately, setting the multicast ports is not as simple as -g and -u. By default, a JBoss Enterprise Application Platform instance running the production configuration will use up to two different instances of the JGroups UDP transport protocol, and will therefore open two multicast sockets. You can control the ports those sockets use by using system properties on the command line. For example,
/run.sh -u 230.1.2.3 -g QAPartition -b 192.168.1.100 -c production \\
        -Djboss.jgroups.udp.mcast_port=12345 -Djboss.messaging.datachanneludpport=23456
The jboss.messaging.datachanneludpport property controls the multicast port used by the MPING protocol in JBoss Messaging's DATA channel. The jboss.jgroups.udp.mcast_port property controls the multicast port used by the UDP transport protocol shared by all other clustered services.
The set of JGroups protocol stack configurations included in the <JBOSS_HOME>/server/production/deploy/cluster/jgroups-channelfactory.sar/META-INF/jgroups-channelfactory-stacks.xml file includes a number of other example protocol stack configurations that the standard JBoss Enterprise Application Platform distribution does not actually use. Those configurations also use system properties to set any multicast ports. So, if you reconfigure a JBoss Enterprise Application Platform service to use one of those protocol stack configurations, use the appropriate system property to control the port from the command line.

Note

It should be sufficient to just change the address, but unfortunately the handling of multicast sockets is one area where the JVM fails to hide operating system behavior differences from the application. The java.net.MulticastSocket class provides different overloaded constructors. On some operating systems, if you use one constructor variant, packets addressed to a particular multicast port are delivered to all listeners on that port, regardless of the multicast address on which they are listening. We refer to this as the promiscuous traffic problem. On most operating systems that exhibit the promiscuous traffic problem (Linux, Solaris and HP-UX) JGroups can use a different constructor variant that avoids the problem. However, on some operating systems with the promiscuous traffic problem (Mac OS X), multicast does not work properly if the other constructor variant is used. So, on these operating systems the recommendation is to configure different multicast ports for different clusters.