Cluster your JBoss environment
Clustering your JBoss environment To make our instances cluster aware, we simply modify how we start up our EAP instances. When we want our instances to be cluster aware, we need to provide at least the following three flags at startup: -g GroupName -u multicastAddress -Djboss.messaging.ServerPeerID=value The combination of GroupName and multicastAddress is what creates cluster uniqueness. By that I mean you could have clusters sharing the same multicast address so long as their group names are different, then they will be in different cluster. If the group names must be the same, then you need a separate multicast address. The last value, ServerPeerID, is used to uniquely identify the instance in the cluster. There is no hard and fast rule on the values here, so long as each instance has a different value. Using a simple sequence is usually easiest to manage. Given these three parameters, then if we wanted to start up two instances (on different servers, just like our example environment) then we would have the following two commands, one for each instance: ./run.sh -c all -g OurCluster -u 239.255.100.100 -b 0.0.0.0 -Djboss.messaging.ServerPeerID=1 ./run.sh -c all -g OurCluster -u 239.255.100.100 -b 0.0.0.0 -Djboss.messaging.ServerPeerID=2 If you have multiple instances on the same machine, please refer to our whitepaper on port management for more information TODO LINK TO PORT MANAGEMENT. When your instances start up, you should see the following in your console: 19:07:46,594 INFO [GroupMember] I am (192.168.1.100:55300) 19:07:46,594 INFO [GroupMember] New Members : 1 ([192.168.1.100:55300]) 19:07:46,594 INFO [GroupMember] All Members : 1 ([192.168.1.100:55300]) And your second instance will show: 19:07:46,594 INFO [GroupMember] I am (192.168.1.100:55300) 19:07:46,594 INFO [GroupMember] New Members : 1 ([192.168.1.100:55300]) 19:07:46,594 INFO [GroupMember] All Members : 2 ([192.168.1.100:55300]) Now our applications are cluster aware. Lets take into consideration our application again. Lets say we want to use sticky sessions (keeps user fixed to one instance to avoid user hopping across EAP instances as well as the need for session replication). Then we still have two points of failure inside our EAP cluster themselves.