SwiftMQ HA Router provides transparent failover to JMS clients, including recovery of all transactions in transit (incl. XA transactions). Processing continues where it stops before the failover. Persistent messages are never lost or delivered twice. Message sequence is guaranteed.
Non-persistent messages in transit may be lost during failover.
To send persistent messages, you must always use the default delivery mode (persistent according to the JMS specification) or specify it explicitly as a parameter of the send/publish method. This guarantees that the send/publish method is processed synchronously and returns only when the router saved the message to disk. Do not send/publish with a default delivery mode of non-persistent and use the Queue Persistency Overwrite Mode to set the message as persistent. In that case the delivery is performed asynchronously and the send/publish method returns before the message has been saved to disk and can lead to message lost.
A call to "receive(timeout)" may time out during failover and return null if the specified timeout is less than the failover time.
Duplicate message detection uses the JMS Message Id. Since it is allowed in JMS to disable the JMS Message Id, it must be enabled (which is default) when using HA. Otherwise duplicate message detection will not work.
Temporary destinations (temp. queues, temp. topics) are reconstructed during failover. They are still valid but now bound to different physical temp. queues at the new HA instance. Since non-persistent messages are lost, a consumer may not receive the expected reply. Further, the consumer of this destination must inform the producer about the new temp. queue or topic after a failover, e.g. by sending the same temporary queue or topic object as JMSReplyTo for the next request.
To avoid that, regular queues (PtP) or durable subscribers (Pub/Sub) with persistent messages can be used for request/reply.
The failover configuration is specified in the connection factory. It contains additional attributes for the 2nd HA instance as well as attributes for reconnect and retry. All these attributes set from the HA Wizard. So actually there is no need to configure it manually.
To receive a reconnect event after a failover, a JMS client can register a reconnect listener at a SwiftMQ connection. The interface is:
package com.swiftmq.jms;
public interface ReconnectListener
{
public void reconnected(String host, int port);
}
"host" and "port" are the host and port of the new HA instance after the failover.
Example to register a reconnect listener:
javax.jms.Connection connection = ...
((com.swiftmq.jms.SwiftMQConnection) connection).addReconnectListener(new ReconnectListener()
{
public void reconnected(String host, int port)
{
// Do stuff
}
});
To see debug output during connect and reconnect, set system property
-Dswiftmq.reconnect.debug=true
at your client's JVM command line. Debug output goes to System.out.