Threading for IBM MQ

The IBM® MQ adapter is thread-safe on the Windowsand AIX® platforms. However, due to the IBM MQ default system configuration parameters for queues and queue managers, the default IBM MQ resources might be insufficient to support multithreading with the IBM MQ adapter.

When operating in the multithreaded mode, the Launcher executes one thread for each map being concurrently executed. In addition to the map thread, the IBM MQ queue manager connection for each distinct queue manager on a source or target card requires a separate connection thread. Because IBM MQ does not allow connection sharing between threads, each map thread maintains its own set of connection threads.

In addition to the map and connection threads, the IBM MQ system spawns threads to service internal requests and processes. The result is that, as the number of concurrent maps increases, the use of IBM MQ and system resources multiplies. When the system resources exceed a threshold based upon the IBM MQ and system configuration settings, the excessive thread context-switching and system memory resource allocation can significantly reduce the efficiency of the overall IBM MQ message throughput.

In addition to the reduction in efficiency, it is possible that when the IBM MQ systems resources are exceeded, the IBM MQ behavior can become unpredictable and can result in messages being ignored on event queues.

To address these limitations, the following recommendations should be implemented:

• Limit the number of concurrent messaging adapter threads to 20. This is a configuration parameter (MaxThreads) set in the dtx.ini file.
• Ensure that the maximum number of handles (queue and queue manager connections) supported by the queue manager exceeds the total number of messaging adapter and IBM MQ threads. This value can be changed by using an MQSC command at the runmqsc prompt as:

  alter qmgr MAXHANDS(2048)

• Set the maximum number of uncommitted messages allowed by the queue manager to an acceptably large value:

  alter qmgr MAXUMSGS(100000)
  

• Set the maximum number of messages allowed on a queue to an acceptable value:

  alter ql(my.queue.name) MAXDEPTH(200000)
  

  The limit on non-z/OS® Batch and CICS® systems is 640K. The queue manager can enforce smaller actual limits based upon DASD resource limitations.