Guaranteed messaging can ensure the delivery of messages between applications, even in cases where the receiving application is offline or there is a failure of a piece of network equipment. Messages are delivered in the order they were published.
Guaranteed messaging keeps messages across event broker restarts by spooling them to persistent storage. The event broker keeps a copy of the message until successful delivery to all clients and downstream event brokers has been verified
Although a persistent delivery mode is typically used for Guaranteed messages, a non-persistent delivery mode is provided to offer compatibility with Java Message Service (JMS), and to allow the delivery mode of the messages to be modified to accommodate the persistence requirements of an endpoint or a client subscription when there is a topic match. For more information, see Topic Matching and Message Delivery Modes.
To support Guaranteed messaging, event brokers must have message spooling enabled. In addition, PubSub+ appliances must also have an Assured Delivery Blade (ADB) installed. Message spooling is enabled by default on PubSub+ Cloud event broker services.
Messages accepted by the event broker through Guaranteed messaging for delivery to clients are never lost, but might not be accepted if system resource limits are exceeded. If an ingress message can't be received by the event broker (for example, if the spool quota is exceeded), the publisher is not acknowledged, and the appropriate event broker statistic is incremented.
Guaranteed Messaging Use Cases
This section provides examples of scenarios where Guaranteed messaging is commonly used:
Message Request Queues
If a queue is created with non-exclusive access mode, consumers can load balance the processing of the message requests. Alternatively, the queue can be made exclusive so that only the first consumer will process requests and the other customers that bind act as backup should the first consumer disconnect. The publishing client is decoupled from knowing how the message items are processed—they simply publish request messages to the queue.
The consumers can also configure their maximum window sizes and maximum unacked messages to set how many message items are pipelined to them in their flows. As each message item is processed, the consumer application triggers an acknowledgment back to the event broker to pull another message into its flow pipeline.
If you need to ensure that messages persist even if all consumers disconnect from the queue, use a durable queue instead of one that's temporary.
It you need to constrain access to the message queue to control which applications can subscribe to the request messages, set a specific user (for example, client user name messageItemProcessor) as the owner of the queue, and set the others permission to none.
Slow Consumers
Guaranteed messaging can be used to buffer messages for slow consumers. For example, a client application that uses a topic subscription to receive Direct messages and then writes them to a database may not be able to keep up with a large burst of messages from a publisher.
To handle such a scenario, the client could create a durable queue and add a topic subscription to it. The topic subscription would attract the messages, which would be changed to non-persistent and spooled to the queue. The client application can then consume and acknowledge without worrying about message rates that overwhelm its processing capabilities. The publisher is also able to publish as quickly as possible and does not need to account for potential slow consuming applications.
Request/Reply with Guaranteed Messages
From a high-level point-of-view, the following steps occur:
- The event broker is provisioned to support Guaranteed messaging.
- The customer application uses a client to create a non-durable queue on the event broker, and then creates a consumer flow to bind to that queue.
- The client publishes a (possibly Guaranteed) message with the request to a well-known topic, specifying that the reply to the request be sent to the newly created temporary queue.
- The event broker listens to the topic (or binds to the queue if it has a topic subscription added to it) and responds to the request by publishing to the specified non‑durable queue.
- The client consumes the reply message from the non-durable queue. Once it has finished processing the responses, it closes the flow, which deletes the non-durable queue.