Rules for Automatic Re-connection

Here are some important rules to keep in mind when using the automatic re-connection feature.

If the Broker disconnects from your client while the client is awaiting a reply from the Broker, a BrokerConnectionClosedException is reflected to the client and no re-connection is attempted.

If your Broker client is using the callback model for event processing, automatic re-connection will be attempted (when necessary) at any of these points:

Each time BrokerClient.dispatch is invoked.

Each time BrokerClient.mainLoop is invoked.

Each time an event is received by the BrokerClient.threadedCallbacks method on a client thread that is still connected.

Broker clients with an explicit-destroy life cycle that are automatically reconnected will find their previous client state has been preserved, including previously registered subscriptions, events in the event queue, and all other client state.

Note:
For Broker clients with an explicit-destroy life cycle, previously retrieved events which were not acknowledged will be presented again after automatic re-connection. When a Broker client that is sharing its state with other clients is disconnected, the other clients retrieve the unacknowledged events. You can avoid receiving duplicate events by explicitly acknowledging events using the BrokerClient.acknowledge, BrokerClient.acknowledgeThrough, or BrokerClient.getEvent methods.

Broker clients with a destroy-on-disconnect life cycle that are automatically reconnected will find that any previously registered subscriptions, events in the event queue, and all other client state will no longer exist. These Broker clients use the connection notification feature to aid them in recreating their previous subscriptions and client state. For more information, see Connection Notification.