I blogged quite extensively on Session Failover mechanism in OpenAM. This component is definitely a must for most production deployment and it is this component which causes quite a headache at times.
Usually it's the problem with installing Java Message Queue in a hardened environment, where firewall is superbly tight. I blogged To Enable Connections Through a Firewall before and I thought it is comprehensive enough to handle all situations.
The loosening of Message Queue PortMapper port and JMS port will only be applicable in a situation like the one illustrated below - Firewall is in-between a pair of OpenAM servers and the MQ Cluster where a pair of Java Message Queue reside.
Now, what if the iptables is enabled on the Java Message Queue server like the one illustrated below?
Well, the simplest thought that comes to mind will be to add the following rules into iptables:
1. Port 7777 for Message Queue PortMapper port
2. Port 17777 for JMS port
No, it will not work. You'll observe the following warning message - Attempting to initiate a cluster connection to mq ... failed: No route to host:
I worked extensively with our network engineer and found out that there is this random port which will be established between the 2 Java Message Queue when they attempt to initiate a cluster.
Looking at the logs, you'll see the following segment:
[05/Aug/2013:14:08:12 ICT] [B1179]: Activated broker
Address = mq://192.168.1.155:7777/?instName=ambrokerext&brokerSessionUID=4870432220830551808
StartTime = 1375678839077
ProtocolVersion = 410
[05/Aug/2013:14:08:12 ICT] [B1071]: Established cluster connection to broker mq://192.168.1.155:7777/?instName=ambrokerext&brokerSessionUID=4870432220830551808[/192.168.1.155:46568]
So what's the solution?
I tried setting my -D options in BROKER_OPTIONS. None will get this random port to become static. So for the time being, we add an iptables rule to each server to allow all ports between the 2 servers.
* Sigh *