Troubleshooting
Problem
In IBM WebSphere Application Server Version 7.0, before Fix Pack 5, 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 application server 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.
Symptom
Work being done by WebSphere MQ messaging provider resources might not complete and errors such as the following might occur in the log files:
| 22/06/08 18:24:41:625 BST] 00000004 TimeoutManage I WTRN0124I: When the timeout occurred the thread with which the transaction is, or was most recently, associated was Thread[WMQJCAResourceAdapter : 0,5,main]. The stack trace of this thread when the timeout occurred was: java.lang.Object.wait(Native Method) java.lang.Object.wait(Object.java:167) com.ibm.mq.jmqi.JmqiWorkerThread.syncExec(JmqiWorkerThread.java:126) com.ibm.mq.jmqi.local.LocalHconn.syncExec(LocalHconn.java:389) com.ibm.mq.jmqi.local.LocalMQ.jmqiConnect(LocalMQ.java:5068) com.ibm.msg.client.wmq.internal.WMQSession.<init>(WMQSession.java:287) |
Resolving The Problem
To prevent the thread pool from becoming exhausted, use the following guidelines to size the thread pool correctly for the application environment.
Note: that this information does not apply to Fix Pack 5 or later since the WMQCommonServices thread pool is no longer used.
Application server environment
If you are using a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory, and all the following conditions apply:
- The connection factory is enabled for two-phase commit
- The transport mode is bindings or bindings, then client
- The bindings leg 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.
Note: The previous information does not apply with WebSphere Application Server for z/OS®, even when you use a connection factory that is enabled for two-phase commit.
If you use a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory and both the following conditions apply:
- The transport mode is client or bindings, then client
- The client leg is used
- 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 that uses the client leg, requires 110 threads.
If you use WebSphere MQ messaging provider activation specifications in either of the following circumstances:
- To deliver messages to message-driven beans inside a transaction with any transport type
- You are using a transport mode of client or bindings, then client, the client leg is used, and a transaction does not exist.
- 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. For more information 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 bindings, then client and the client leg is used.
For example, each WebSphere MQ messaging provider activation specification with a client transport mode, and that is enabled for two-phase commit, requires 12 threads.
If you use message listener ports that use WebSphere MQ messaging provider resources to deliver messages to MDBs, you need to 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.
Then:
- You require one thread for each connection that is 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 message listener port instance for the connection consumer object, if the following conditions are true:
- 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 bindings, then client
- Uses the bindings leg
If the WebSphere MQ messaging provider connection factory has a transport mode of client or bindings, then client, and uses the client leg, 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 that is used by the connection consumer object, if the following message listener port conditions are true:
- Uses a WebSphere MQ messaging provider connection factory
- Has a transport mode of client or bindings, then client
- Uses the client leg
Note: For each installed MDB that is 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 you install a single MDB using a message listener port which 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 that is 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 need to allow 112 threads: 10 for the connection pool, 100 for the session pools, one for the exception listener, and one for the connection consumer.
Application client environment
In the application client environment, the rules for thread requirements are similar to those rules in the application server 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 you use a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory and both the following conditions apply:
- The transport mode is client or bindings, then client
- The client leg is used
- You require one thread for each connection
- You require one thread for each session
If you are 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 bindings, then client, and the client leg is used.
If you register an exception listener implementation with a connection, you need an extra thread.
Consider the following scenario:
An IBM AIX application server installation has a single MDB installed. The MDB has transactions managed by the Enterprise JavaBeans (EJB) 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 specification 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))
Configuring WMQCommonServices thread pool size in an application server
You need to configure every application server that uses WebSphere MQ messaging provider resources and the default WMQCommonServices thread pool size is not enough. For example, if the MDB that is used in the previous example is deployed in a clustered environment with two servers, perform the following procedure on both application servers 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 application server, perform the following steps using the administrative console:
- Click Servers > Server Types > WebSphere Application Servers > server name.
- Under Additional Properties, click Thread pools> WMQCommonServices.
- Update the value of the Maximum size field to the relevant value and click OK.
- Click Save and restart the application server.
Configuring WMQCommonServices thread pool size in an application client
To configure the maximum size of the WMQCommonServices thread pool in the application client container, complete the following steps:
- Create a file called wmq.client.props, and put it in the application client class path.
- 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
- Save the changes.
Related Information
[{"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Java Message Service (JMS)","Platform":[{"code":"PF002","label":"AIX"},{"code":"PF010","label":"HP-UX"},{"code":"PF012","label":"IBM i"},{"code":"PF016","label":"Linux"},{"code":"PF027","label":"Solaris"},{"code":"PF033","label":"Windows"}],"Version":"7.0","Edition":"Base;Express;Network Deployment","Line of Business":{"code":"LOB45","label":"Automation"}},{"Product":{"code":"SS7K4U","label":"WebSphere Application Server for z\/OS"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Component":"Not Applicable","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"7.0","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21317935