Sizing the thread pools used by the WebSphere MQ messaging provider

Use this task to calculate the number of thread pools required by the WebSphere MQ messaging provider.

Almost all of the work that is done by the WebSphere MQ messaging provider uses threads from the WMQCommonServices thread pool. By default, this thread pool has a maximum size of 40 threads in an appserver environment and 10 threads in a client environment. If the number of threads is exceeded, work that is submitted by the WebSphere MQ messaging provider might not complete and errors might be output to the log files. If the system logs contain one or more messages with a message key of CWSJY0011W, the thread pool is reaching maximum capacity. When the thread pool reaches maximum capacity, one or more messages with a key of CWSJY0010E are output to the logs.

To prevent the thread pool from becoming exhausted, use the following guidelines to size the thread pool correctly for the application environment.

 

1. Application Server environment If using a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory, and both the following conditions apply:

   • The connection factory is enabled for two-phase commit

   • The transport mode is bindings, or the transport mode is bindings, then client and a bindings mode connection is used

   then:

   • You require one thread for each connection. Allow enough threads to fill up the connection pool, which has a default maximum size of 10.

   • You require one thread for each session. Allow enough threads to fill up the session pool, which has a default maximum size of 10. There is one session pool for every connection in the connection pool.

   For example, each WebSphere MQ messaging provider connection factory with a bindings transport mode, and that is enabled for two-phase commit, requires 110 threads.

   The previous information does not apply with WAS for z/OS , even when you use a connection factory that is enabled for two-phase commit.

   If we use a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory and either of the following condition apply:

   • The transport mode is client

   • The transport mode is bindings, then client and a client mode connection is used

   then:

   • You require one thread for each connection. Allow enough threads to fill up the connection pool, which has a default maximum size of 10.

   • You require one thread for each session. Allow enough threads to fill up the session pool, which has a default maximum size of 10. There is one session pool for every connection in the connection pool.

   For example, each WebSphere MQ messaging provider connection factory with a transport mode of bindings, then client, and which uses a client mode connection, requires 110 threads. If we use WebSphere MQ messaging provider activation specifications in any of the following circumstances:

   • To deliver messages to message-driven beans inside a transaction with any transport type

   • we are using a transport mode of client and a transaction does not exist

   • we are using a transport mode of bindings, then client, a client mode connection is used, and a transaction does not exist

   then:

   • You require one thread for each running message-driven bean (MDB) instance. The number of instances is determined by the maximum server sessions setting on a WebSphere MQ messaging provider activation specification. By default this value is 10.

   • You require one thread for each five MDB installations, if they all connect to the same queue manager. The default value for the WebSphere MQ messaging provider connectionConcurrency setting is 5.

     See on how to set the connectionConcurrency setting, refer to the Information Center for WebSphere MQ.

   • You require one extra thread to perform the dispatching of messages if the transport mode is client, or the transport mode is bindings, then client and a client mode connection is used.

   For example, each WebSphere MQ messaging provider activation spec with a client transport mode, and that is enabled for two-phase commit, requires 12 threads.

   If we use message listener ports that use WebSphere MQ messaging provider resources to deliver messages to MDBs, take account of the thread pool considerations for the connections and sessions that are used by the message listener port instances.

   The message listener port uses one session for each server session. By default, there is one server session for each message listener port instance. If both the following conditions apply:

   • The message listener port is using a WebSphere MQ messaging provider connection factory that is enabled for two-phase commit

   • The transport mode is bindings, or the transport mode is bindings, then client and a bindings mode connection is used

   then:

   • You require one thread for each connection used by a message listener port instance. This thread is for the exception listener with which it is registered.

   • You require one thread for each session.

   If the WebSphere MQ messaging provider connection factory has a transport mode of client, or has a transport mode or bindings, then client and a client mode connection is used, one thread is required regardless of whether the connection factory is enabled for two-phase commit. You require one thread for each message listener port instance for the dispatch thread used by the connection consumer object, if the following message listener port conditions are true:

   • The message listener port is using a WebSphere MQ messaging provider connection factory

   • The transport mode is client, or the transport mode is bindings, then client and a client connection mode is used

   For each installed MDB configured to use a particular message listener port, there is a single message listener port instance. For example, if three MDBs are configured to use the same message listener port, there are three message listener port instances. If we install a single MDB using a message listener port that uses a WebSphere MQ messaging provider connection factory in bindings mode, and that is enabled for two-phase commit, you require at least four threads:

   • One thread for the connection

   • One thread for the session used inside the server session, which is used by the message listener port

   • One thread for the exception listener

   • One thread for the connection consumer

   However, if the MDB is stopped and started, a different connection and therefore a different set of sessions might be retrieved from the pool. You must allow 112 threads: 10 for the connection pool, 100 for the session pools, one for the exception listener, and one for the connection consumer.

2. Application client environment

   In the application client environment, the rules for thread requirements are similar to those rules in the appserver environment. However, the rules are simplified because connection and session pooling is not used, and connection factories cannot take part inside a transaction. For most application clients, the default maximum thread pool size of 10 should be sufficient. If we use a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory and either of the following conditions apply:

   • The transport mode is client

   • The transport mode is bindings, then client and a client mode connection is used

   then:

   • You require one thread for each connection

   • You require one thread for each session

   If registering a message listener implementation with a session for asynchronous delivery of messages, you require an extra thread if the WebSphere MQ messaging provider connection factory that created the session has a transport mode of client, or has a transport mode of bindings, then client and a client mode connection is used.

   If we register an exception listener implementation with a connection, we need an extra thread.

   Consider the following scenario:

   An IBM AIX appserver installation has a single MDB installed. The MDB has transactions managed by the EJBs container and has a transaction attribute of required, so messages are delivered to the MDB under an XA transaction. The MDB is configured to use a WebSphere MQ messaging provider activation spec with transport mode of bindings. When a message is received, the MDB performs some processing and then sends a reply message using WebSphere MQ messaging provider connection factory with a transport mode of bindings. The connection factory has the default connection and session pool settings. The number of threads that are used by this scenario is 121 and consists of the following threads:

   • 10 (one thread * default maximum number of MDB instances)

   • 1 (the thread that is shared across deployments)

   • 10 (the thread used by pooled connection * default pool size of 10)

   • 100 (the thread used by pooled session * default connection pool size(10) * default session pool size (10))

3. Set WMQCommonServices thread pool size in an application server

   You must configure every appserver that uses WebSphere MQ messaging provider resources and the default WMQCommonServices thread pool size is not enough. For example, if the MDB used in the previous example is deployed in a clustered environment with two servers, perform the following procedure on both appservers to set the size of the WMQCommonServices thread pool to at least 121. To configure the maximum size of the WMQCommonServices thread pool in the appserver, perform the following steps using the admin console:

   1. Click Servers > Server Types > WebSphere application servers > server_name .

   2. Under Additional Properties, click Thread pools > WMQCommonServices .

   3. Update the value of the Maximum size field to the relevant value and click OK.

   4. Click Save and restart the application server.

4. Set WMQCommonServices thread pool size in an application client To configure the maximum size of the WMQCommonServices thread pool in the application client container...

   1. Create a file called wmq.client.props, and put it in the application client class path.

   2. Edit the wmq.client.props file and add the following text to the file:

      com.ibm.ws.wmqcsi.threadPoolMaximumSize=<desired size of thread pool>
      

      For example: com.ibm.ws.wmqcsi.threadPoolMaximumSize=15

   3. Save the changes.

 

Related tasks

Tuning messaging
Create a connection factory for the WebSphere MQ messaging provider using the Create JMS Resource wizard