Putting messages asynchronously in IBM MQ classes for JMS

Normally, when an application sends messages to a destination, the application has to wait for the queue manager to confirm that it has processed the request. We can improve messaging performance in some circumstances by choosing instead to put messages asynchronously. When an application puts a message asynchronously, the queue manager does not return the success or failure of each call, but we can instead check for errors periodically.

Whether a destination returns control to the application, without determining whether the queue manager has received the message safely, depends upon the following properties:

  • The JMS Destination Property PUTASYNCALLOWED (short name - PAALD).

    PUTASYNCALLOWED controls whether JMS applications can put messages asynchronously, if the underlying queue or topic that the JMS Destination represents, allows this option.

  • The IBM MQ queue or topic property DEFPRESP (Default put response type).

    DEFPRESP specifies whether applications that put messages to the queue, or publish messages to the topic, can make use of the asynchronous put functionality.

The following table shows the possible values for the PUTASYNCALLOWED and DEFPRESP properties, and what values are required for the asynchronous put functionality to be enabled:
Table 1. PUTASYNCALLOWED and DEFPRESP properties determining if messages are put asynchronously.
JMS Destination property PUTASYNCALLOWED = NO PUTASYNCALLOWED = YES PUTASYNCALLOWED = AS_DEST or AS_Q_DEF or AS_T_DEF
IBM MQ queue property      
DEFPRESP=SYNC Asynchronous put functionality not enabled Asynchronous put functionality enabled Asynchronous put functionality not enabled
DEFPRESP=ASYNC Asynchronous put functionality not enabled Asynchronous put functionality enabled Asynchronous put functionality enabled

For messages sent in a transacted session, the application ultimately determines whether the queue manager has received the messages safely when it calls commit().

If an application sends persistent messages within a transacted session, and one or more of the messages are not received safely, the transaction fails to commit and produces an exception. However, if an application sends nonpersistent messages within a transacted session, and one or more of the messages are not received safely, the transaction commits successfully. The application does not receive any feedback that the nonpersistent messages did not arrive safely.

For nonpersistent messages sent in a session that is not transacted, the SENDCHECKCOUNT property of the ConnectionFactory object specifies how many messages are to be sent, before IBM MQ classes for JMS checks that the queue manager has received the messages safely.

If a check discovers that one or more messages were not received safely, and the application has registered an exception listener with the connection, IBM MQ classes for JMS calls the onException() method of the exception listener to pass a JMS exception to the application.

The JMS exception has an error code of JMSWMQ0028 and this code displays the following message: 
At least one asynchronous put message failed or gave a warning.

The JMS exception also has a linked exception that provides more details. The default value of the SENDCHECKCOUNT property is zero, which means that no such checks are made.

This optimization is of most benefit to an application that connects to a queue manager in client mode, and needs to send a sequence of messages in rapid succession, but does not require immediate feedback from the queue manager for each message sent. However, an application can still use this optimization even if it connects to a queue manager in bindings mode, but the expected performance benefit is not as great.