Timers define a limit to the amount of time that is required
for a specific operation to complete. The type of operation a timer
controls determines when the time period, that is set for that timer,
starts to elapse.
Timer properties as they relate to configuring your
message-driven beans to work with listener ports or activation specifications.
For
WebSphere® Application Server Version 7 and later, listener ports are
deprecated. Therefore 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. In some cases you will continue to use the WebSphere
MQ message-driven bean deployment and listener ports and in other
case you will use the WebSphere MQ message-driven bean deployment
and activation specifications.
The following properties DO
NOT apply to activation specification driven message-driven bean deployment.
That is, the properties require you to configure them to use the WebSphere
MQ message-driven bean deployment and listener ports:
- control_region_mdb_request_timeout
- control_region_mdb_queue_timeout_percent
- server_region_mdb_stalled_thread_dump_action
The follow properties DO apply to activation specification
driven message-bean deployment. That is, these properties require
you to configure them to use the WebSphere MQ message-driven bean
deployment and activation specifications.
- control_region_wlm_dispatch_timeout
- control_region_iiop_queue_timeout_percent
- server_region_iiop_stalled_thread_dump_action
As you follow the instructions to configure these properties,
remember what properties apply to listener ports versus activation
specifications.
Most timers have a default value that defines a reasonable
time period, during which a particular operation should complete.
When the time limit specified for the timer elapses, the product takes
one of the following actions:
- Sends a minor code to the client if the time limit elapses before
the client request is dispatched to a servant.
- Abnormally ends the servant with an EC3 ABEND if the time limit
elapses while the client request is being processed by an application
component running in the servant.
In this situation all of the
threads in this servant are terminated. The servant is also terminated
to prevent the application from holding resources, and thereby preventing
other requests from using these resources. After the servant is terminated,
workload management (WLM) starts a new servant to take the place of
the servant that was terminated.
Avoid trouble: The
total transaction lifetime timeout and the maximum transaction timeout
have grace periods beyond the timeout value specified of approximately
four minutes. This extended time period must elapse before an ABEND
occurs.
gotcha
Different types of timers might reach their time limits
simultaneously, because the operations they control might overlap
to a certain degree. For example, suppose the application server receives
an IIOP client request that is processed by an application component
that uses transaction support. In this case, both of the following
timers count down simultaneously:
- control_region_wlm_dispatch_timeout, which limits both the amount
of time a client request waits on the WLM queue, as well as the time
required for the application component to process the request
- transaction_defaultTimeout, which limits the amount of time
the controller waits for a transaction to be either committed or rolled
back
These timers overlap only for the time during which the
transaction is processed. To determine which timer cause the error,
you can use the symptoms- specific minor codes or EC3 abend reason
codes.
To determine the occurrence of a timeout as quickly as
possible and to prevent further resource locking, WebSphere Application Server prevents further transactional work on the transactional path
where the timeout condition has taken place. This applies equally
to attempting to perform work under the current transaction context
and to attempting to perform work under a different transactional
context.
The timers that are used to control processing behavior
can be classified into five general types. These general types, and
the operations that they control, are summarized in the following
table.
Table 1. Summary of
general types. The timers that are used to control processing
behavior can be classified into five general types. These general
types, and the operations that they control, are summarized in the
following table.
General
type |
Timer
processing |
Timeout
symptoms |
Input |
Input
timers define limits for receiving a complete request; the countdown
starts when a connection to the J2EE server is established. The communication
protocol (HTTP, HTTPS) determines the timer used for the request. |
The
session is closed. |
Session |
Session
timers define limits for the use of session connections. These timers
start the countdown as soon as a session becomes idle. |
The
session is closed. |
WLM
dispatch |
Dispatch
timers control how long a complete client request waits to be dispatched
in a servant region for processing. For some dispatch timers, an additional
value can be specified that designates the percent of the dispatch
time as the timeout value for the WLM queue. If this time is exceeded,
then the work is removed from the WLM queue, but an abend is not issued
for the servant. The countdown starts when the controller places the
request on the WLM queue. Depending on the specific timer, the time
limit can include both the wait time on the WLM queue, and the time
required for processing a response to the client request. |
Message
BBOO0327I for all timeouts. If the servant is terminated, then
Message BBOO0232W and an EC3 ABEND are displayed in the servant, with
one of the following reason codes:
- 04130003
- 04130004
- 04130006
|
Transaction |
Transaction
timers define how long:
- An application or controller waits for one transaction to complete.
The countdown starts when the container starts a transaction on behalf
of the application component.
- A controller attempts to recover in-doubt transactions during
peer restart and recovery mode.
|
Message
BBOT0003W or BBOO0232W, and an EC3 ABEND are displayed in the servant,
with one of the following reason codes:
|
Output |
Output
timers define how long a controller waits to receive output for a
client request. The countdown starts when the client request is dispatched
to the servant for processing. The communication protocol (HTTP or
HTTPS) determines the timer used for the request. |
Message
BBOO0232W and an EC3 ABEND are displayed in the servant, with reason
code 04130007. |
|