![[z/OS]](../images/ngzos.gif)
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 you 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:
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:
|
Transaction | Possible causes of transaction timeouts include:
|
See the possible solutions for WLM dispatch timeouts. In addition, you can look for messages indicating contention for resources that are 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, you 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. |