Configure Clients for Shared State Failover Connections

When a failover occurs and the standby server takes the active state, clients attempt to reconnect to this server (that is, the new active server). To enable a client to reconnect, you must specify the URLs of both servers when creating a connection.

Specify multiple servers as a comma-separated list of URLs. Both URLs must use the same protocol (either tcp or ssl). For example, to identify the first server as tcp://server0:7222, and the second server as tcp://server1:7344 (if first server is not available), you can specify: 

   serverUrl=tcp://server0:7222, tcp://server1:7344

The client attempts to connect to each URL in the order listed. If a connection to one URL fails, the client tries the next URL in the list. The client tries the URLs in sequence until all URLs have been tried. If the first failed connection was not the first URL in the list, the attempts wrap to the start of the list (so each URL is tried).

For information on how to lookup a fault-tolerance URL in the EMS naming service, see Perform Fault-Tolerant Lookups.

Note: The reconnection logic in the client is triggered by the specifying multiple URLs when connecting to a server. If no secondary server is present, the client must still provide at least two URLs (typically pointing to the same server) in order for it to automatically reconnect to the server when it becomes available after a failure.
Note: When messages are sent in non-persistent or reliable modes, the consumer does not normally wait for a server reply to its acknowledgements. However, a fault tolerant consumer does wait for a server reply (when using an session mode other than DUPS_OK_ACKNOWLEDGE or EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE). This is true for shared state configurations. Unshared state configurations, which tolerate lost, duplicated, and out-of-order messages during a failover, do not wait for server acknowledgements.