Consuming a Message

Messages are received by a message consumer, within the context of a connection and session. A client uses a message consumer object (MessageConsumer) to receive messages from a specified physical destination, represented in the API as a destination object.

Three factors affect how the broker delivers messages to a consumer:

• Whether consumption is synchronous or asynchronous

• Whether a selector is used to filter incoming messages

• If messages are consumed from a topic destination, whether the subscriber is durable

The other major factor that affects message delivery and client design is the degree of reliability needed for the consumer. See Reliable Messaging.

Synchronous and Asynchronous Consumers

A message consumer can support either synchronous or asynchronous consumption of messages.

• Synchronous consumption means the consumer explicitly requests that a message be delivered and then consumes it.

  Depending on the method used to request messages, a synchronous consumer can choose to wait (indefinitely) until a message arrives, to wait a specified amount of time for a message, or to return immediately if there is no message ready to be consumed. (“Consumed” means the object is immediately available to the client. Messages that were successfully sent but which the broker has not finished processing are not ready to be consumed.)

• Asynchronous consumption means that the message is automatically delivered to a message listener object (MessageListener) that has been registered for the consumer. The client consumes the message when a session thread invokes the onMessage() method of the message listener object.

Using Selectors to Filter Messages

A message consumer can use a message selector to have the message service deliver only those messages whose properties match specific selection criteria. You specify this criteria when you create the consumer.

Selectors use an SQL-like syntax to match against message properties. For example,

color = ”red’
size > 10

Java clients can also specify selectors when browsing a queue; this allows you to see which selected messages are waiting to be consumed.

Using Durable Subscribers

You can use a session object to create a durable subscriber to a topic. The broker retains messages for these kinds of subscribers even when the subscriber becomes inactive.

Because the broker must maintain state for the subscriber and resume delivery of messages when the subscriber is reactivated, the broker must be able to identify a given subscriber throughout its comings and goings. The subscriber’s identity is constructed from the ClientID property of the connection that created it and the subscriber name specified when you create the subscriber.