| Skip Navigation Links | |
| Exit Print View | |
|
Oracle GlassFish Server Message Queue 4.5 Technical Overview |
1. Messaging Systems: An Introduction
Domain-Specific and Unified APIs
Connection Factories and Connections
Synchronous and Asynchronous Consumers
Using Selectors to Filter Messages
A. Message Queue Implementation of Optional JMS Functionality
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:
Payload messages, which are the messages sent by producers to consumers.
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.
Figure 2-7 Message Delivery Steps
Message delivery steps for a persistent, reliably delivered message are as follows:
1. The client runtime delivers the message over the connection from the message producer to the broker.
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 confirms 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 subscriber, thereby causing a message in a topic destination to be removed without it being delivered. The broker can also discard a message before it is consumed if the message has expired, if memory limits have been reached, or if delivery fails due to a client exception. If you don't want a message discarded in these situations, you can have the broker store the messages in a special destination called the dead message queue. Storing messages in the dead message queue allows you to troubleshoot the system and recover messages in any of these situations.
|