Fault tolerance examples for SonicMQ
- Last Updated: February 11, 2026
- 1 minute read
- OpenEdge
- Version 13.0
- Documentation
Fault tolerant connections allow another SonicMQ Broker to take over if the original SonicMQ Broker fails. To ensure message delivery, use the fault-tolerant APIs to setup and enable fault tolerance. These APIs include the setFaultTolerant procedure, the getFaultTolerant function, the isFaultTolerant function, the setConnectionURLs procedure, the setFaultTolerantReconnectTimeout procedure, the getFaultTolerantReconnectTimeout function, the setInitialConnectionTimeout procedure, the getInitialConnectionTimeout function, the setClientTransactionBufferSize procedure, the getClientTransactionBufferSize function, and the createChangeStateConsumer procedure. Although you setup and enable fault tolerance from the SonicMQ client, the SonicMQ Broker must support it.
After creating the session object, you must create the list of SonicMQ Brokers to use, set the fault tolerant property for the session, and then start the session.
Fault tolerance set up
The following example shows how to set up a fault tolerant session.
|
Example of a "ChangeState" handler (optional)
When the connection to the SonicMQ Broker is lost, SonicMQ has the ability
to notify the application. A special asynchronous handler, "ChangeState" handler, notifies
the client application whenever the state of the SonicMQ Broker changes. The character
header property of the message passed to the "ChangeState" handler contains one of the
following values: active, reconnecting, failed, or closed. You setup the handler by calling the createChangeStateConsumer procedure after to calling the beginSession procedure.
The following code sample shows how to use the createChangeStateConsumer procedure.
|