If a SwiftMQ Router is shutdown (e.g. due to an upgrade) and restarted or a network problem occured, JMS clients can transparent reconnect to the same SwiftMQ Router without any additional coding.
SwiftMQ Router 6.0.0 onwards provides transparent reconnect to JMS clients to the same SwiftMQ Router, including recovery of all transactions in transit (incl. XA transactions). Processing continues where it stops before the reconnect. Persistent messages are never lost or delivered twice if the router was orderly shutdown or uses disk-sync for its transaction log (see Store Swiftlet). Message sequence is guaranteed.
Non-persistent messages in transit may be lost during reconnect.
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 reconnet and return null if the specified timeout is less than the reconnect 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 transparent reconnect. Otherwise duplicate message detection will not work.
Duplicate message detection for all queues and queue controllers is enabled by default.
Duplicate message detection for JMS connection factories are disabled at a SwiftMQ Router Standard (non-HA). It must be enabled for transparent reconnect.
Temporary destinations (temp. queues, temp. topics) are reconstructed during reconnect. They are still valid but now bound to different physical temp. queues at the new router 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 reconnect, 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 reconnect configuration is specified in the connection factory. It contains additional attributes for reconnect and retry. These attributes are disabled by default. The pictures marks also attributes for a 2nd HA instance. These attributes are for SwiftMQ HA Router only. Transparent reconnect only requires attributes "Reconnect Enabled", "Reconnect Delay", "Reconnect Max. Retries", "Duplicate Message Detection" of the connection factory.
The reconnect attributes of a connection factory are read-only. To change it via SwiftMQ Explorer/CLI, the connection factory must be deleted and recreated (and the configuration must be saved).
To receive a reconnect event after a reconnect has been completed, 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 router instance after the reconnect.
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.