[Windows][UNIX][Linux]

Message delivery reliability with AMQP

There are four features of the IBM® MQ Light API that allow you to control the reliability of message delivery to, and from, MQ Light and AMQP applications.

These are:

Message quality of service (QOS)

The MQ Light API offers two qualities of service:

  • At most once
  • At least once

You can choose which quality of service you want publishers and subscribers to use.

If you are using an MQ Light client, set the client or subscribe qos option to QOS_AT_MOST_ONCE or QOS_AT_LEAST_ONCE.

If you are using a different AMQP client, set the settled attribute of the transfer frame (for publishers), or the disposition frame (for subscribers) to true or false, depending on the quality of service you want to achieve.

The quality of service determines when a message is discarded from the sending side of a conversation.

Publishing

If a publisher chooses QOS 0 (at most once) the publisher does not wait for an acknowledgment from the queue manager, before it discards its copy of the message.

If the connection to the queue manager fails before the send has completed, the message might not be received by subscribers.

If a publisher chooses QOS 1 (at least once) the publisher waits for the queue manager to acknowledge that the message has been written to subscriber queues before discarding its copy of the message.

If the connection to the queue manager fails during the send, the publisher re-sends the message once it has reconnected to the queue manager.

Subscribing

If a subscriber chooses QOS 0 the queue manager does not wait for an acknowledgment from the subscriber before discarding its copy of the message.

If the connection to the subscriber fails before the subscriber has received the message, that message might be lost.

If a subscriber chooses QOS 1 the queue manager waits for an acknowledgment from the subscriber before discarding its copy of the message.

If the connection to the subscriber fails before the subscriber has received the message, the message is kept by the queue manager. The queue manager re-sends the message to the subscriber when the queue manager reconnects, or to another subscriber if the subscription is shared.

Subscriber auto-confirm

If a subscriber chooses QOS 1 (at least once) it must acknowledge receipt of each message before the queue manager discards its copy. The subscriber can decide when it acknowledges messages.

With auto-confirm set to true, the MQ Light client automatically acknowledges delivery of each message, once the client has successfully received the message over the network.

This ensures that if there is a network failure, the message is redelivered to the application. However, it is still possible for the application to lose the message, if the application fails in between the MQ Light client acknowledging the message, and the application processing it.

With auto-confirm set to false, the MQ Light client does not automatically acknowledge delivery of the message, but leaves it to the application to decide when it should be acknowledged.

This allows an application to make an update to an external resource, such as a database or a file, before acknowledging to the queue manager that the message has now been processed and can be discarded.

Subscription time to live

When an application subscribes, it chooses whether the subscription, and the destination where messages are stored for that subscription, continue to exist after the application disconnects.

The MQ Light subscribe option ttl is used to specify the time (in milliseconds) that a subscription continues to exist after the application disconnects. If the application reconnects before this time, the subscription is resumed and the application can continue to consume messages from that subscription.

If the time-to-live period passes without the application reconnecting, the subscription is removed and any messages stored on its destination are lost, even if they are persistent messages.

If it is important not to lose messages, you must specify a time-to-live value to the application, that is high enough to ensure messages are not lost during an outage.

Message persistence

The persistence of messages is controlled by the publishing and subscribing applications, and the configuration of IBM MQ topic objects.

If the AMQP subscriber uses QOS 0 (at most once) and creates a non-durable subscription, the AMQP channel always puts non-persistent messages to the subscriber queue, regardless of the other options described in the following text.

Note that, if the queue manager is stopped both the subscription and the messages will be lost.

If an AMQP publisher sets the AMQP durable header to true, the AMQP channel puts persistent messages to subscriber queues.

If the queue manager is stopped for any reason, the messages are still available to subscribers when the queue manager is restarted.

If the durable header is not set, the AMQP channel chooses the persistence of published messages based on the DEFPSIST attribute of the relevant IBM MQ topic object.

By default, this is the SYSTEM.BASE.TOPIC, which uses a DEFPSIST attribute of NO (non-persistent).

Attention: Later versions of the MQ Light client do not support setting the AMQP durable header.