Storing undeliverable messages

Messaging and ESB

Implementing Messaging : Managing connections and sessions : Client persistence : 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 15. Managing client persistence
Setting	Getting
setLocalStoreDirectoryprocedure setLocalStoreSizeprocedure setReconnectTimeoutprocedure setReconnectIntervalprocedure setClientPersistenceprocedure createRejectedMessageConsumer procedure	getLocalStoreDirectoryfunction getLocalStoreSizefunction getReconnectTimeoutfunction getReconnectIntervalfunction getClientPersistencefunction

Additionally, client persistence requires using the setClientIDprocedure. The clientID must be unique for each client. The application may optionally call the setPingIntervalprocedure 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.

For an example of client persistence, see Client persistence.