Client persistence provides a higher level of reliability than is defined in the JMS specification. Client persistence allows the JMS session to continue sending messages regardless of the SonicMQ Broker status. If the SonicMQ Broker is not available, the messages are stored locally and sent when the SonicMQ Broker becomes available.

Note: Client persistence is only available to OpenEdge clients running in ClientConnect mode.

Storing undeliverable messages

When the connection to the SonicMQ Broker fails, messages are persisted to disk, and replayed when the connection is re-established. Each connection must have a local directory specified where messages will be stored when a connection fails.

The following table lists the methods for managing client persistence.

Table 1. Managing client persistence
Setting Getting
setLocalStoreDirectory procedure, setLocalStoreSize procedure, setReconnectTimeout procedure, setReconnectInterval procedure, setClientPersistence procedure, createRejectedMessageConsumer procedure getLocalStoreDirectory function, getLocalStoreSize function, getReconnectTimeout function, getReconnectInterval function, getClientPersistence function

Additionally, client persistence requires using the setClientID procedure. The clientID must be unique for each client. The application may optionally call the setPingInterval procedure to enable connection checking between the client and the SonicMQ Broker.

Note: Creating a Rejected Message Listener is also optional. This listener notifies the client when a message is rejected during playback.

The caller must ensure that the connections to the machine and port number are correct. It is possible for messages to be lost if an incorrect broker is specified. Although the messages will be persisted to disk, they will never be sent since there will never be a broker to connect to.

Note: Client persistence does not support Message Consumers and transacted sessions.