You can tune message-driven beans processing when you are
running WebSphere® Application Server on the z/OS® platform,
where WebSphere 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.
To tune
message-driven bean processing, consider all the following settings
together:
- WLM service class definitions
- WebSphere Application Server workload profile
selection
- Message listener service listener port settings
- JMS Connection Factory pooling settings
- WebSphere MQ Queue Manager settings
It is difficult to recommend values to select for each
of these settings, given the variety of workloads that can be run
in any given server. There are many possibilities to consider, including
the following factors:
- 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
- Set the listener port maximum sessions property
to at least twice the maximum number of servant worker threads available
to the entire server. The value of this property determines
the high threshold value (high threshold = maximum sessions), and
is used by the throttle to decide when to block or allow requests.
- Start the administrative console.
- In the navigation pane, click
The Message listener port collection panel is displayed.
- Select the name of the listener port that you want to
work with. The Listener port settings panel
is displayed.
- Set the maximum sessions property
to the value you want the message-driven bean throttle to use as its
high threshold value. The suggested minimum value is computed
by the formula:
2 * (maximum number of servants) * (number of worker threads in one servant)
Here "servants" means the same as "server
instances" on the administrative console. To calculate the number
of worker threads in a single servant, see the description of "Workload
profile" in ORB services advanced
settings.
For more information about setting the Listener
Port maximum sessions property, see Message-driven beans and tuning settings on z/OS.
- Set the WebSphere MQ queue connection
factory properties.
- To view this administrative console page, click .
- Select the queue connection factory specified for the
listener port.
- From the Additional Properties, select the Connection
Pool panel.
- Set the Max Connections property
for the Connection Pool. Allow one connection for each
message-driven bean. This property value might include message-driven
beans mapped onto different listener ports, if those listener ports
were each, in turn, mapped onto the same connection factory. For more
detailed discussions about this setting,
see Message-driven beans and tuning settings on z/OS.
- From the Additional Properties of the queue connection
factory, select the Session Pool panel.
- Set the Max Connections property
for the session pool. Allow one session for each worker
thread in a single servant. Set this property to at least the number
of worker threads available to a single servant. For more detailed
discussions about this setting, see Message-driven beans and tuning settings on z/OS.
- Set the WebSphere MQ-related properties.
Make sure that the backing WebSphere MQ
queue manager has been configured with enough resources to support
the intended JMS workload coming from WebSphere Application
Server (and other clients). In particular, consider your queue manager
CTHREAD, IDBACK, and IDFORE parameter settings. For more information
on these WebSphere MQ settings, see the WebSphere MQ books:
- WebSphere MQ System Setup Guide (SC34-6052-02)
- WebSphere MQ Script Command (MQSC) Reference
Book (SC34-6055-03)
- WebSphere MQ Problem Determination Guide
(GC34-6054-01)
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 MDB throttle support for z/OS debugging tips.