JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Technical Overview
search filter icon
search icon

Document Information


1.  Messaging Systems: An Introduction

2.  Client Programming Model

Messaging Domains

Point-To-Point Messaging

Publish/Subscribe Messaging

Domain-Specific and Unified APIs

Programming Objects

Connection Factories and Connections



Message Header

Message Properties

Message Body

Producing a Message

Consuming a Message

Synchronous and Asynchronous Consumers

Using Selectors to Filter Messages

Using Durable Subscribers

The Request-Reply Pattern

Reliable Message Delivery



Local Transactions

Distributed Transactions

Persistent Storage

A Message's Journey Through the System

Message Production

Message Handling and Routing

Message Consumption

Message End-of-Life

Design and Performance

Working with SOAP Messages

Java and C Clients

3.  The Message Queue Broker

4.  Broker Clusters

5.  Message Queue and Java EE

A.  Message Queue Implementation of Optional JMS Functionality

B.  Message Queue Features



A Message’s Journey Through the System

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:

Message delivery is illustrated in Figure 2-7.

Figure 2-7 Message Delivery Steps

image:Diagram showing steps in the message delivery process in case of a persistent, reliably delivered message. Figure is described in text.

Message delivery steps for a persistent, reliably delivered message are as follows:

Message Production

1. The client runtime delivers the message over the connection from the message producer to the broker.

Message Handling and Routing

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.

Message Consumption

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.

Message End-of-Life

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.