JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle GlassFish Server Message Queue 4.5 Developer's Guide for Java Clients
search filter icon
search icon

Document Information

Preface

1.  Overview

2.  Using the Java API

3.  Message Queue Clients: Design and Features

Client Design Considerations

Developing Portable Clients

Choosing Messaging Domains

Connections and Sessions

Producers and Consumers

Assigning Client Identifiers

Message Order and Priority

Using Selectors Efficiently

Balancing Reliability and Performance

Managing Client Threads

JMS Threading Restrictions

Thread Allocation for Connections

Managing Memory and Resources

Managing Memory

Managing Message Size

Message Compression

Advantages and Limitations of Compression

Compression Examples

Managing the Dead Message Queue

Managing Physical Destination Limits

Programming Issues for Message Consumers

Using the Client Runtime Ping Feature

Preventing Message Loss for Synchronous Consumers

Synchronous Consumption in Distributed Applications

Factors Affecting Performance

Delivery Mode (Persistent/Nonpersistent)

Use of Transactions

Acknowledgment Mode

Durable vs. Nondurable Subscriptions

Use of Selectors (Message Filtering)

Message Size

Message Body Type

Connection Event Notification

Connection Events

Creating an Event Listener

Event Listener Examples

Consumer Event Notification

Consumer Events

Creating a Consumer Event Listener

Consumer Event Listener Examples

Client Connection Failover (Auto-Reconnect)

Enabling Auto-Reconnect

Single-Broker Auto-Reconnect

Parallel Broker Auto-Reconnect

Clustered-Broker Auto-Reconnect

Auto-Reconnect Behaviors

Auto-Reconnect Limitations

Handling Exceptions When Failover Occurs

Handling Exceptions in a Transacted Session

Transacted Session: Failover Producer Example

Transacted Session: Failover Consumer Example

Handling Exceptions in a Non-Transacted Session

Failover Producer Example

Failover Consumer Example

Custom Client Acknowledgment

Using Client Acknowledge Mode

Using No Acknowledge Mode

Schema Validation of XML Payload Messages

Communicating with C Clients

Client Runtime Logging

Logging Name Spaces, Levels, and Activities

Using the JRE Logging Configuration File

Using a Logging Configuration File for a Specific Application

Setting the Logging Configuration Programmatically

4.  Using the Metrics Monitoring API

5.  Working with SOAP Messages

6.  Embedding a Message Queue Broker in a Java Client

A.  Warning Messages and Client Error Codes

Index

Custom Client Acknowledgment

Message Queue supports the standard JMS acknowledgment modes (auto-acknowledge, client-acknowledge, and dups-OK-acknowledge). When you create a session for a consumer, you can specify one of these modes. Your choice will affect whether acknowledgment is done explicitly (by the client application) or implicitly (by the session) and will also affect performance and reliability. This section describes additional options you can use to customize acknowledgment behavior:

The following sections explain how you program these options.

Using Client Acknowledge Mode

For more flexibility, Message Queue lets you customize the JMS client-acknowledge mode. In client-acknowledge mode, the client explicitly acknowledges message consumption by invoking the acknowledge() method of a message object. The standard behavior of this method is to cause the session to acknowledge all messages that have been consumed by any consumer in the session since the last time the method was invoked. (That is, the session acknowledges the current message and all previously unacknowledged messages, regardless of who consumed them.)

In addition to the standard behavior specified by JMS, Message Queue lets you use client-acknowledge mode to acknowledge one message at a time.

Observe the following rules when implementing custom client acknowledgment:

If a broker fails, any message that was not acknowledged successfully (that is, any message whose acknowledgment ended in a JMSException) is held by the broker for delivery to subsequent clients.

Example 3-6 demonstrates both types of custom client acknowledgment.

Example 3-6 Example of Custom Client Acknowledgment Code

...
import javax.jms.*;
...[Look up a connection factory and create a connection.]

    Session session = connection.createSession(false,
                       Session.CLIENT_ACKNOWLEDGE);

...[Create a consumer and receive messages.]

    Message message1 = consumer.receive();
    Message message2 = consumer.receive();
    Message message3 = consumer.receive();

...[Process messages.]

...[Acknowledge one individual message.
   Notice that the following acknowledges only message 2.]

    ((com.sun.messaging.jms.Message)message2).acknowledgeThisMessage();

...[Continue. Receive and process more messages.]

    Message message4 = consumer.receive();
    Message message5 = consumer.receive();
    Message message6 = consumer.receive();

...[Acknowledge all messages up through message 4. Notice that this 
    acknowledges messages 1, 3, and 4, because message 2 was acknowledged 
    earlier.]

    ((com.sun.messaging.jms.Message)message4).acknowledgeUpThroughThisMessage();
...[Continue. Finally, acknowledge all messages consumed in the session.
    Notice that this acknowledges all remaining consumed messages, that is, 
    messages 5 and 6, because this is the standard behavior of the JMS API.]

    message5.acknowledge();

Using No Acknowledge Mode

No-acknowledge mode is a nonstandard extension to the JMS API. Normally, the broker waits for a client acknowledgment before considering that a message has been acknowledged and discarding it. That acknowledgment must be made programmatically if the client has specified client-acknowledge mode or it can be made automatically, by the session, if the client has specified auto-acknowledge or dups-OK-acknowledge. If a consuming client specifies no-acknowledge mode, the broker discards the message as soon as it has sent it to the consuming client. This feature is intended for use by nondurable subscribers consuming nonpersistent messages, but it can be used by any consumer.

Using this feature improves performance by reducing protocol traffic and broker work involved in acknowledging a message. This feature can also improve performance for brokers dealing with misbehaving clients who do not acknowledge messages and therefore tie down broker memory resources unnecessarily. Using this mode has no effect on producers.

You use this feature by specifying NO_ACKNOWLEDGE for the acknowledgeMode parameter to the createSession, createQueueSession, or createTopicSession method. No-acknowledge mode must be used only with the connection methods defined in the com.sun.messaging.jms package. Note however that the connection itself must be created using the javax.jms package.

The following are sample variable declarations for connection, queueConnection and topicConnection:

javax.jms.connection Connection;
javax.jms.queueConnection queueConnection
javax.jms.topicConnection topicConnection

The following are sample statements to create different kinds of no-acknowledge sessions:

//to create a no ack session
Session noAckSession  =
     ((com.sun.messaging.jms.Connection)connection)
    .createSession(com.sun.messaging.jms.Session.NO_ACKNOWLEDGE);

// to create a no ack topic session
TopicSession noAckTopicSession  =
     ((com.sun.messaging.jms.TopicConnection) topicConnection)
    .createTopicSession(com.sun.messaging.jms.Session.NO_ACKNOWLEDGE);

//to create a no ack queue session
QueueSession noAckQueueSession  =
     ((com.sun.messaging.jms.QueueConnection) queueConnection)
    .createQueueSession(com.sun.messaging.jms.Session.NO_ACKNOWLEDGE);

Specifying no-acknowledge mode for a session results in the following behavior: