Auto-Reconnect Limitations

Notice the following points when using the auto-reconnect feature:

Messages might be redelivered to a consumer after auto-reconnect
takes place. In auto-acknowledge mode, you will get no more than one redelivered
message. In other session types, all unacknowledged persistent messages are
redelivered.

While the client runtime is trying to reconnect, any messages
sent by the broker to nondurable topic consumers are lost.

Any messages that are in queue destinations and that are unacknowledged
when a connection fails are redelivered after auto-reconnect. However, in
the case of queues delivering to multiple consumers, these messages cannot
be guaranteed to be redelivered to the original consumers. That is, as soon
as a connection fails, an unacknowledged queue message might be rerouted to
other connected consumers.

In the case of a conventional broker cluster, the failure
of the master broker prevents the following operations from succeeding on
any other broker in the cluster:

Creating or destroying a new durable subscription.

Creating or destroying a new physical destination using the imqcmd create dst command.

Starting a new broker process. (However, the brokers that
are already running continue to function normally even if the master broker
goes down.)

You can configure the master broker to restart automatically
using Message Queue broker support for rc scripts or the
Windows service manager.

Auto-reconnect doesn’t work if the client uses a ConnectionConsumer to consume messages. In that case, the client runtime throws an
exception.