Timeout conditions - possible causes and fixes

(zos)
Timeout conditions - possible causes and fixes

This file lists common timer variables and tools for monitoring these timeout conditions
The timer that expires first might not indicate the actual problem that needs to be fixed. To properly diagnose timeout conditions, you should know all of the timer values that might be in effect for a particular servant region.

General type of timer Possible causes Possible solutions
Input The client sent only part of the data and was delayed in sending the rest. The application on the client side may want to consider having retry logic in place if it does receive a timeout minor code in return.
Session The session is idle through lack of use. If we consider losing idle sessions to be a problem, increase the values of the persistent-session timeouts, or use the session more frequently.
WLM dispatch No threads are free to pick up the request because of one of the following conditions:

The threads are all busy processing requests.

The currently executing threads are waiting for a response from DB2 , WebSphere MQ, another server, and so on. In this case, look for messages indicating contention for resources; for example, on the z/OS console, you might see messages about DB2 deadlocks.

In either case, the request times out waiting in the WLM queue to be dispatched in a servant (region).
The case where the threads are all busy processing requests could indicate one of the following conditions:

The number of servant regions that WLM may start is set too low. To set this value, on the console select Servers >Application Servers >server_name >Server Instance. Click on Multiple Instances Enabled and specify a value for Maximum Number of Instances.

The number of threads allowed within a servant region is set too low. The number is controlled by the Isolation Policy setting in Administrative console or WebSphere variable: server_region_ workload_profile

You need to replicate servers to handle the amount of incoming work.
All of these conditions indicate that performance tuning might be necessary.
Transaction Possible causes of transaction timeouts include:

The same as those for WLM dispatch timeouts, or

Delays that prevent the transaction coordinator from committing or rolling back a transaction within the allotted time.

See the possible solutions for WLM dispatch timeouts. In addition, we can look for messages indicating contention for resources involved in the transaction that timed out.
Output Possible causes of output timeouts are the same as those for WLM dispatch (dispatch is for IIOP, output is for HTTP). See the possible solutions for WLM dispatch timeouts. In addition, we can use the WebSphere variable protocol_accept_ http_work _after_min_srs=1 to prevent the HTTP transport handler from dispatching requests until WLM starts a minimum number of servant regions.

Related tasks

Troubleshooting administration

Timer overview
Timeout conditions: analyzing diagnostic data
Timeout values: guidelines for altering timeout values

General type of timer	Possible causes	Possible solutions
Input	The client sent only part of the data and was delayed in sending the rest.	The application on the client side may want to consider having retry logic in place if it does receive a timeout minor code in return.
Session	The session is idle through lack of use.	If we consider losing idle sessions to be a problem, increase the values of the persistent-session timeouts, or use the session more frequently.
WLM dispatch	No threads are free to pick up the request because of one of the following conditions: The threads are all busy processing requests. The currently executing threads are waiting for a response from DB2 , WebSphere MQ, another server, and so on. In this case, look for messages indicating contention for resources; for example, on the z/OS console, you might see messages about DB2 deadlocks. In either case, the request times out waiting in the WLM queue to be dispatched in a servant (region).	The case where the threads are all busy processing requests could indicate one of the following conditions: The number of servant regions that WLM may start is set too low. To set this value, on the console select *Servers >Application Servers >server_name* >Server Instance. Click on Multiple Instances Enabled and specify a value for Maximum Number of Instances**. The number of threads allowed within a servant region is set too low. The number is controlled by the Isolation Policy setting in Administrative console or WebSphere variable: server_region_ workload_profile You need to replicate servers to handle the amount of incoming work. All of these conditions indicate that performance tuning might be necessary.
Transaction	Possible causes of transaction timeouts include: The same as those for WLM dispatch timeouts, or Delays that prevent the transaction coordinator from committing or rolling back a transaction within the allotted time.	See the possible solutions for WLM dispatch timeouts. In addition, we can look for messages indicating contention for resources involved in the transaction that timed out.
Output	Possible causes of output timeouts are the same as those for WLM dispatch (dispatch is for IIOP, output is for HTTP).	See the possible solutions for WLM dispatch timeouts. In addition, we can use the WebSphere variable protocol_accept_ http_work _after_min_srs=1 to prevent the HTTP transport handler from dispatching requests until WLM starts a minimum number of servant regions.