This is part of a series of blog posts which will cover features of IBM MQ that I happen to be using this week. I spend a lot of time using MQ, and not everything counts as an MQ Little Gem, or a Quirk, but is still interesting to hear about. Read other posts in this series.
Asynchronous Put Response is a performance enhancing feature that was introduced in MQ V7. It is sometimes referred to as "Fire and Forget".
It helps performance when you are doing lots of puts of messages over a network connection. It does so by recognising that, for every put message request, there is a line turnaround to deliver the response to the put call, and that this response is often very uninteresting because almost all put calls work. So it removes that response altogether.
When an application chooses to use this feature, it has three choices about what it can do about the fact that it will not get a response to the put call (failing or successful).
- It might not care
If the application will re-issue the put again in a moment, if no response is forthcoming, it might not care about whether the put worked or failed. This sort of behaviour might be appropriate for inquiry style applications, including those making inquiries of the queue manager's command server, e.g. lists of queues.
- It might periodically check
If the application is putting large numbers of messages, and is using Asynchronous put response to improve the performance of this, it can periodically check whether any puts failed, by using the MQSTAT verb. So perhaps every 50 MQPUT calls, it could then issue an MQSTAT call and that will report on whether any of the last 50 puts failed.
- Transactional persistent message behaviour
If the application is putting persistent messages in a transaction and is using Asynchronous put response to improve the performance of this, when the transaction is committed, if any of the prior put calls failed, the MQCMIT will fail in order to ensure the integrity of the transaction.
This behaviour only applies for persistent messages in a transaction. If you are only putting non-persistent messages in a transaction, should any of the puts fail, the MQCMIT will still succeed.
This feature can be used in one of two ways.
- The application can be explicitly coded the use of the option MQPMO_ASYNC_RESPONSE - this is a change to the application code
- An administrator can turn on the option by using the queue attribute DEFPRESP(ASYNC) - doing this is outside of the application code
Clearly in the first case, the application is making a change, and it is appropriate at the same time to review whether adding a call to MQSTAT should accompany this change to the application code.
In the second case however, the application may not be aware that asynchronous put is in use. If it is operating transactionally, and persistent messages are in use, then the fact that the MQCMIT will fail, in place of MQPUT failures, means that the transaction will be rolled back, just as, it is likely, it would have been if the application had been informed of MQPUT failures.
However, if the application is using transactions which might sometimes only contain non-persistent messages, the same cannot be said. The application will not be aware if the MQPUT fails and the MQCMIT will also not fail if only non-persistent messages are in the transaction. An example of this might be an application that is used to move messages from one queue to another. It is likely that such pattern will use transactions, and will expect therefore to find that the messages are either on the source queue or on the target queue when the application ends. It might come as a surprise then if some messages are on neither queue and have been discarded.
The important point to note here is, only turn on DEFPRESP(ASYNC) if you are OK to have non-persistent messages discarded if there are any MQPUT failures, or if you know that the application uses MQSTAT to determine failures have happened.
Some recent updates have been made to IBM Docs to highlight this behaviour too.
#Using-MQ-feature
#IBMMQ
#IBMChampion