Use this task to calculate the number of thread pools required by the WebSphere® MQ messaging provider.
This
task is not required for Fix Pack 5 or later since the WMQCommonServices
thread pool is no longer used.
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. 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.
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.
If you use a WebSphere MQ messaging provider connection factory, topic connection factory or queue connection factory and either of the following condition apply:
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.
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 must take account of the thread pool for the connections and sessions that are used by the message listener port instances.
For WebSphere Application Server Version 7 and later, listener ports are stabilized. For more information, read the article on stabilized features. You should plan to migrate your WebSphere MQ message-driven bean deployment configurations from using listener ports to using activation specifications. However, you should not begin this migration until you are sure the application does not have to work on application servers earlier than WebSphere Application Server Version 7. For example, if you have an application server cluster with some members at Version 6.1 and some at Version 7, you should not migrate applications on that cluster to use activation specifications until after you migrate all the application servers in the cluster to Version 7.
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 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.
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.
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 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 has a transport mode of bindings, then client and a client mode connection 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.
You must 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, complete the following procedure on both application servers to set the size of the WMQCommonServices thread pool to at least 121.
com.ibm.ws.wmqcsi.threadPoolMaximumSize=<required size of thread pool>
For example: com.ibm.ws.wmqcsi.threadPoolMaximumSize=15
In this information ... | IBM Redbooks, demos, education, and more(Index) Use IBM Suggests to retrieve related content from ibm.com and beyond, identified for your convenience. This feature requires Internet access. Most of the following links will take you to information that is not part of the formal product documentation and is provided "as is." Some of these links go to non-IBM Web sites and are provided for your convenience only and do not in any manner serve as an endorsement by IBM of those Web sites, the material thereon, or the owner thereof. |