Session Failover with Sun GlassFish(tm) Message Queue 4.4 - Part IV

Assuming we have 2 active OpenAM servers configured as a site with session failover running. The underlying component used for session failover is a pair of Sun GlassFish(tm) Message Queue 4.4.

am1.cdemo.sg:7676 (Primary) and am2.cdemo.sg:7777 (Secondary)

What happens when the primary MQ (am1.cdemo.sg:7676) instance goes down?

The following will be captured in the Session debug log:


INFO: [I107]: Connection recover state: RECOVER_INACTIVE, broker: am1.cdemo.sg:7676(17777)
Apr 17, 2013 3:58:21 PM com.sun.messaging.jmq.jmsclient.ConnectionRecover logRecoverState
INFO: [I107]: Connection recover state: RECOVER_TRANSPORT_CONNECTED, broker: am2.cdemo.sg:7777(17777)
Apr 17, 2013 3:58:21 PM com.sun.messaging.jmq.jmsclient.ConnectionRecover logRecoverState
INFO: [I107]: Connection recover state: RECOVER_STARTED, broker: am2.cdemo.sg:7777(17777)
Apr 17, 2013 3:58:21 PM com.sun.messaging.jmq.jmsclient.ConnectionRecover logRecoverState
INFO: [I107]: Connection recover state: RECOVER_IN_PROCESS, broker: am2.cdemo.sg:7777(17777)
Apr 17, 2013 3:58:21 PM com.sun.messaging.jmq.jmsclient.ConnectionRecover logRecoverState
INFO: [I107]: Connection recover state: RECOVER_SUCCEEDED, broker: am2.cdemo.sg:7777(17777)

We can see that am1.cdemo.sg:7676 (Primary node) is immediately recognized as Inactive, and am2.cdemo.sg:7777 (Secondary node) is "started" to take over as the Active node.

A "Deactivated broker" message will be captured in the secondary MQ debug log:

[17/Apr/2013:15:58:18 SGT] [B1180]: Deactivated broker 
Address = mq://192.168.1.51:7676/?instName=ambroker&brokerSessionUID=1259668788178645760
StartTime = 1366181153149
ProtocolVersion = 410

And right immediately after that, all MQ connections from OpenAM servers will be established on the secondary MQ.


[17/Apr/2013:15:58:18 SGT] [B1065]: Accepting: amuser@192.168.1.52:40287->jms:17777. Count: service=2 broker=2
[17/Apr/2013:15:58:18 SGT] [B1065]: Accepting: amuser@192.168.1.52:40286->jms:17777. Count: service=2 broker=2
[17/Apr/2013:15:58:21 SGT] [B1122]: Reconnecting client 1259668788186075904
[17/Apr/2013:15:58:21 SGT] [B1065]: Accepting: amuser@192.168.1.52:40298->jms:17777. Count: service=3 broker=3

Now, what happens when the Primary node (am1.cdemo.sg:7676) is restarted?

My observation is:

1. The OpenAM servers will continue to communicate with the last active node, which is Secondary node (am2.cdemo.sg:7777)
2. They will only be communicate with the Primary node (am1.cdemo.sg:7676) again upon OpenAM restart.

=> This follows the Database URL : am1.cdemo.sg:7676,am2.cdemo.sg:7777 which was initially configured during Site setup

Nice!

/