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

used to control processing behavior can be classified into five general types. These general types, and the operations that they
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.

Related tasks

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