Replication Best Practices

This section describes considerations that should be made when your client applications are to be used with Solace PubSub+ event brokers using the Replication facility, which provides a data center redundancy and disaster recovery solution for Solace PubSub+.

Messaging API Versions

It is strongly recommended that Replication-aware applications use release 7.1.2 or later Solace enterprise messaging APIs. These versions support automatic handling of replication failovers. When a replication failover occurs, the API properly handles any in-progress messages or transactions.

Host Lists

Applications should be configured with a host list of two addresses, one for the Guaranteed Messaging-enabled virtual router at each site. The addresses can be either IP addresses or hostnames.

When the application attempts to connect to a standby event broker, the connection will be rejected by the event broker. After the specified number of retries per host, the API will attempt to connect to the other host in the host list. Normally, for an application to be used with Replication, if a connection fails for one host it would be good to immediately attempt to connect to the other host before retrying the same host. Therefore, setting a reconnect retries per host of 1 is recommended.

Host lists should not be used if you are using an active/active Replication deployment, where clients are consuming messages from endpoints on the Replication active Message VPN or on its mate Replication standby Message VPN. For such a deployment, each consuming client should only attempt to connect to the Replication active Message VPN on one host or the Replication standby Message VPN on its mate.

Automatic Reconnect

When using a Solace messaging API's automatic reconnect feature, it should be noted that the duration of a Replication failover will be minutes or hours because operator intervention is required for the switchover. Therefore, it is recommended to set the number of reconnect retries to -1, which allows a client application to attempt to reconnect indefinitely.

For an example of how to handle Replication reconnects, see the Replication sample that is included with the Solace messaging API that you are using.

Queue Network Names

The queue network name interface has been deprecated in the APIs with the release of Replication. The reason is that queue network names change between different virtual routers, but Replication applications need to ensure queue naming is consistent within a paired Replication site.

For the C messaging API, it is recommended to provide the application queue name directly as the SOLCLIENT_ENDPOINT_PROP_NAME and the SOLCLIENT_FLOW_PROP_BIND_NAME, rather than obtaining the name from a call to solClient_createQueueNetworkName(), which is a deprecated function.

For the JCSMP Messaging API, it is recommended to call JCSMPFactory.createQueue(String name) rather than JCSMPFactory.createQueue(String name, String virtualRouterName. The latter is a deprecated method.