By way of summarizing the material presented so far, this section describes how a message is delivered using the Message Queue service, from a producer to a consumer. In order to paint a complete picture, a further detail is needed: The messages handled by the system in the course of delivery fall into two categories:
Control messages, which are private messages passed between the broker and the client runtime to ensure that payload messages are successfully delivered and to control the flow of messages across a connection.
Message delivery is illustrated in Figure 2–7.
Message delivery steps for a persistent, reliably delivered message are as follows:
2. The broker reads the message from the connection and places it in the appropriate destination.
3. The broker places the (persistent) message in the data store.
4. The broker acknowledges receipt of the message to the client runtime of the message producer.
5. The broker determines the routing for the message.
6. The broker writes out the message from its destination to the appropriate connection, tagging it with a unique identifier for the consumer.
7. The message consumer’s client runtime delivers the message from the connection to the message consumer.
8. The message consumer’s client runtime acknowledges consumption of the message to the broker.
9. The broker processes the client acknowledgement, and deletes the (persistent) message when all acknowledgements have been received.
10. The broker confirms to the consumer’s client runtime that the client acknowledgement has been processed.
The broker can discard a message before it is consumed if the administrator deletes the message from a destination or if the administrator removes or redefines a durable subscription, thereby causing a message in a topic destination to be removed without it being delivered. In other situations, you might want the broker to store the messages in a special destination called the dead message queue rather than discard them. A message is placed on the dead message queue when it expires, when it is removed due to memory limits, or when delivery fails due to the client’s throwing an exception. Storing messages in the dead message queue allows you to troubleshoot the system and recover messages in certain situations.