Guaranteed Messaging Use Cases

This section provides examples of scenarios where Guaranteed Messaging functionality can be used:

Message Request Queues

If the 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 producers to the message queue are 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, make use of a durable queue instead of one that's temporary.

As well, if you need to constrain access to the message queue so that not just anyone can access 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 receiving applications.

Request/Reply with Guaranteed Messages

From a high-level point-of-view, the following steps occur:

  1. The event broker is provisioned to support Guaranteed messaging.
  2. 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.
  3. 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.
  4. The server 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.
  5. The client consumes the reply message from the non-durable queue. Once it has finished processing the response(s), it closes the flow, which deletes the non-durable queue.