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.