Asynchronous consumption of IBM MQ messages
Asynchronous consumption uses a set of Message Queue Interface (MQI) extensions, the MQI calls MQCB and MQCTL, which allow an MQI application to be written to consume messages from a set of queues. Messages are delivered to the application by invoking a 'unit of code', identified by the application passing either the message, or a token representing the message.
In the most straightforward of application environments, the unit of code is defined by a function pointer, however in other environments the unit of code can be defined by a program or module name.
In asynchronous consumption of messages, the following terms are used:
- Message consumer
- A programming construct that allows you to define a program, or function, to be invoked with a message when one which matches the applications requirement becomes available.
- Event handler
- A programming construct that allows you to define a program or function to invoke when an asynchronous event, such as queue manager quiescing, occurs.
- Callback
- A generic term used to refer to either a Message Consumer or an Event Handler routine.
Asynchronous consumption can simplify the design and implementation of new applications, especially those that process multiple input queues or subscriptions. However, if you are using more than one input queue and you are processing messages in priority sequence, priority sequence is observed independently within each queue: you might get low-priority messages from one queue ahead of high-priority messages from another. Message order across multiple queues is not guaranteed. Also note that if we use API exits, you might need to change them to include the MQCB and MQCTL calls.
The following illustrations give an example of how we can use this function.
Figure 1 shows a multithreaded application consuming messages from two queues. The example shows all of the messages being delivered to a single function.
On z/OS®, the main control thread must issue an MQDISC call before ending. This allows any callback threads to end and release system resources.
Figure 2 This sample flow shows a single threaded application consuming messages from two queues. The example shows all of the messages being delivered to a single function.
The difference from the asynchronous case is that control does not return to the issuer of MQCTL until all of the consumers have deactivated themselves; that is one consumer has issued an MQCTL STOP request or the queue manager quiesces.