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:

You can customize the JMS client-acknowledge mode to acknowledge one message at a time.

If performance is key and reliability is not a concern, you can use the proprietary no-acknowledge mode to have the broker consider a message acknowledged as soon as it has been sent to the consuming client.

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:

To acknowledge an individual message, call the acknowledgeThisMessage() method. To acknowledge all messages consumed so far, call the acknowledgeUpThroughThisMessage() method. Both are shown in the following code example.

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:

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

The client runtime will throw a JMSException if Session.recover() is called.

The client runtime will ignore a call to the Message.acknowledge() method from a consumer.

Messages can be lost. As opposed to dups-OK-acknowledge, which can result in duplicate messages being sent, no-acknowledge mode bypasses checks and balances built into the system and may result in message loss.