Understanding how timers work

This file gives an overview of understanding timers

Timers define a limit to the amount of time required for a specific operation to complete. When the timer begins its countdown depends on type of operation it controls. The timers that WebSphere Application Server for z/OS uses can be classified into the general types described later in this article; the specific timers themselves are described in Timeout values - controlling behavior. Most of the timers have a default value that defines a reasonable limit for the particular operation to complete. When the timer pops (that is, reaches the time limit), WebSphere Application Server for z/OS takes one of the following actions:

Different types of timers might be counting down simultaneously, because the operations they control might overlap to a certain degree. For example, suppose the application server receives an IIOP client request that will be processed by an application component that uses transaction support. In this case, both of the following WebSphere timers can be counting down simultaneously:

These timers overlap only for the time during which the application's transaction is being processed. To determine which timer cause the error, you can use the symptoms- specific minor codes or EC3 ABEND reason codes.

General types of timers and the operations they control

[/reference/refbody/section/table/tgroup/colspec {"- topic:colspec "}) (colspec][/reference/refbody/section/table/tgroup/colspec {"- topic:colspec "}) (colspec][/reference/refbody/section/table/tgroup/colspec {"- topic:colspec "}) (colspec]
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. The countdown starts when the controller places the request on the WLM queue. Depending on the specific timer, the time limit can include not only wait time on the WLM queue, but also the time required for processing a response to the client request. Message BBOO0232W and an EC3 ABEND in the servant (region), with one of these accompanying reason codes:
Transaction Transaction timers define how long:
  • An application or controller will wait for one transaction to complete. The countdown starts when the container starts a transaction on behalf of the application component.
  • A controller will attempt to recover in-doubt transactions during peer restart and recovery mode.
  • Message BBOT0003W or BBOO0232W
  • An EC3 ABEND in the servant (region), with one of these accompanying reason codes:
Output Output timers define how long a controller will wait to receive output for a client request. The countdown starts when the client request is dispatched to the servant region for processing. The communication protocol (HTTP, HTTPS) determines the timer used for the request. Message BBOO0232W and an EC3 ABEND in the servant (region), with reason code 04130007



Related reference
Guidelines for analyzing diagnostic data for timeout conditions
Identifying possible causes of and fixes for timeout conditions
Guidelines for altering timeout values



Searchable topic ID:   rtrb_understandingtimers
Last updated: Jun 21, 2007 9:56:50 PM CDT    WebSphere Application Server for z/OS, Version 5.0.2
http://publib.boulder.ibm.com/infocenter/wasinfo/index.jsp?topic=/com.ibm.websphere.zseries.doc/info/zseries/ae/rtrb_understandingtimers.html

Library | Support | Terms of Use | Feedback