Auto-Reconnect Behaviors

A broker treats an automatic reconnection as it would a new connection.
When the original connection is lost, all resources associated with that connection
are released. For example, in a broker cluster, as soon as one broker fails,
the other brokers assume that the client connections associated with the failed
broker are gone. After auto-reconnect takes place, the client connections
are recreated from scratch.

Sometimes the client-side state cannot be fully restored by auto-reconnect.
Perhaps a resource that the client needs cannot be recreated. In this case,
the client runtime calls the client’s connection exception handler and
the client must take appropriate action to restore state. For additional information,
see Handling Exceptions When Failover Occurs.

If the client is automatically-reconnected to a different broker instance,
effects vary depending on the clustering model used.

In a conventional cluster, persistent messages produced but
not yet consumed may only be delivered to the consumer after the original
broker recovers. Other state information held by the failed or disconnected
broker can be lost. The messages held by the original broker, once it is restored,
might be delivered out of order.

In a high availability cluster, messages produced but not
yet consumed continue to be delivered to the consumer without the original
broker needing to recover.

A transacted session is the most reliable method of ensuring that a
message isn’t lost if you are careful in coding the transaction. If
auto-reconnect happens in the middle of a transaction, any attempt to produce
or consume messages will cause the client runtime to throw a JMSException. In this case, applications must call Session.rollback() to
roll back the transaction.

The Message Queue client runtime may throw a TransactionRolledBackException when Session.commit() is called during or after
a failover occurs. In this case, the transaction is rolled back and a new
transaction is automatically started. Applications are not required to call Session.rollback() to rollback the transaction after receiving a TransactionRolledBackException.

The Message Queue client runtime may throw a JMSException when Session.commit() is called during or after a failover occurs. In
this case, the transaction state is unknown (may or may not be committed).
Applications should call Session.rollback() to roll back
the uncommitted transaction.

If you are using a high availability cluster, the only time your transaction
might wind up in an unknown state is if it is not possible to reconnect to
any brokers in the cluster. This should happen rarely if ever. For additional
information, see Handling Exceptions When Failover Occurs.

Automatic reconnection affects producers and consumers differently:

During reconnection, producers cannot send messages. The production
of messages (or any operation that involves communication with the message
broker) is blocked until the connection is reestablished.

For consumers, automatic reconnection is supported for all
client acknowledgment modes. After a connection is reestablished, the broker
will redeliver all unacknowledged messages it had previously delivered, marking
them with a Redeliver flag. The client can examine this
flag to determine whether any message has already been consumed (but not yet
acknowledged). In the case of nondurable subscribers, some messages might
be lost because the broker does not hold their messages once their connections
have been closed. Any messages produced for nondurable subscribers while the
connection is down cannot be delivered when the connections is reestablished.
For additional information, see Handling Exceptions When Failover Occurs.