Put 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.

The JMS destination property PUTASYNCALLOWED (short name - PAALD).

PUTASYNCALLOWED controls whether JMS applications can put messages asynchronously, if this option is allowed by the underlying queue or topic that the JMS destination represents.

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 use asynchronous put functionality.

The following table shows the possible values for the PUTASYNCALLOWED and DEFPRESP properties, and the combinations of values used to enable asynchronous put functionality:

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.

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.