Tuning message-driven bean processing on z/OS by using IBM MQ as the messaging provider in ASF mode
You can tune message-driven beans processing when you are running WebSphere® Application Server on the z/OS® platform, where IBM MQ is the messaging provider, and the message-driven bean has been deployed in Application Server Facilities (ASF) mode.
Before you begin
To tune message-driven bean processing, you need to consider a variety of settings together. There are a wide range of values and possibilities to consider, because of the variety of workloads possible to run in any given server.
When a message-driven bean is mapped (that is, listening to) a queue, or to a topic through a
durable subscription, a JMS message first enters into the application server in the controller, so
we say the server is listening in the controller
for these messages. The listening in the
controller
term is used throughout this description of tuning message-driven bean
processing.
About this task
When you are tuning message-driven bean processing in the server, you also need to consider the tuning the entire workload for the server, and the interaction between the two.
- WLM service class definitions
- WebSphere Application Server workload profile selection
- Message listener service listener port settings
- JMS Connection Factory pooling settings
- IBM MQ Queue Manager settings
- The number of message-driven beans.
- The administrative configuration choices, such as whether to map two message-driven beans to the same or different listener ports.
- The importance of work for message-driven beans compared with other (HTTP, IIOP) types of work running in the server.
The following suggested settings provide a starting point, and assume that the server is configured with only one application, which consists of a single message-driven bean that is installed and running on this server.
More detailed discussions explain the rationale behind the suggestions, and describe the listener
port function in more detail in the listening in the controller
case on z/OS. Together, they can help you to make your own setting selections for your
own systems and servers.
Procedure
Example
- If your server is configured with the maximum server instances value set
to 3, (whatever the minimum number might be), and if your workload profile is
LONGWAIT (which means that each servant contains 40 worker threads), set your
listener port maximum sessions value to at least
240 = 2 * 3 * 40
- Suppose that your application contains two individual message-driven beans, each of which has an
onMessage() implementation that forwards the message to another JMS destination. Therefore, each
message-driven bean needs its own JMS connection factory to complete this task. Suppose the
Administrator has mapped each message-driven bean JMS connection factory resource reference onto the
same administratively-defined connection factory used by the listener port that each of these
message-driven beans is mapped onto.
In this case, you need to set the connection factory Connection Pool Max Connections value to 42. One connection for each of the two message-driven beans to be used by the listener port, and one connection potentially for each of the 40 onMessage() dispatches that night be running concurrently. (Remember that the connection pool is a per-servant pool).
- Set the connection factory Session Pool Max Connections to 40, the number of worker threads in a single servant, regardless of the number of servants.
For debugging tips, refer to Optimizing MDB throttle support for debugging in z/OS.