Timer overview

(ZOS) Timer overview

Timers define a limit to the amount of time required for a specific operation to complete. The type of operation a timer controls determines when the time period, set for that timer, starts to elapse.

Timer properties as they relate to configuring the message-driven beans to work with listener ports or activation specifications.

For WebSphere Application Server v7 and later, listener ports are deprecated. Therefore we should plan to migrate your IBM MQ message-driven bean deployment configurations from using listener ports to using activation specifications. Do not this migration until we are sure the application does not have to work on application servers earlier than WAS v7. In some cases we will continue to use the IBM MQ message-driven bean deployment and listener ports and in other case we will use the IBM 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 IBM 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 IBM 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.

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..

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, we 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, WAS 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 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:

04130002
04130005

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.

Troubleshoot administration
Timeout conditions: analyzing diagnostic data
Timeout conditions - possible causes and fixes
Timeout values: guidelines for altering timeout values
Timeout properties summary

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: 04130002 04130005
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.