Timeout values: guidelines for altering timeout values

This file lists common timer variables and tools for monitoring these timeout conditions

Generally speaking, increasing the timeout values should be your last resort, or only a temporary action taken to prevent multiple timeout-abend dumps from causing system performance problems. If you increase timeout values without properly diagnosing the timeout condition, the only results you might see are less frequent abends and dumps for the same timeout condition, or slower system or application performance.

For information on how to set values for these timer variables, and how these variables map to internal variables, see Controlling behavior through timeout values

(Some WebSphere® variables are split on multiple lines for printing purposes.)

Table 1. Common timer variables and tools for monitoring these timeout conditions . Ensure that you diagnose the timeout condition before increasing timeout values.
WebSphere variable and its relationship, if any, to other timers	How to monitor processing for this type of timeout condition:	If you want to adjust the value, consider the following:
`WLM timeout` For HTTP work and Scalable Messaging Support, the WLM timer is not set and only the ConnectionResponseTimeout is in effect (covering the entire dispatch window)	SMF provides data on WLM queue time	How long work takes to get to a servant depends on the number of servants that WLM starts, how many you let it start, how many service classes the work is spread across, how much work you're getting, and so on.
`ConnectionIOTimeOut` None.	This behavior is not easily monitored. Turning on a trace point would indicate whether a client failed because of this input timeout setting, but tracing has performance consequences.	How long are you willing to allow a control region worker thread to be blocked while it is waiting for a message? How big are incoming HTTP requests? The larger they are, the longer it might take to get the whole request through the network.
`ConnectionResponseTimeout` If the application component starts transactions, then the transaction timers also might be involved.	This behavior is not easily monitored, but the controller will terminate the servant (region) with abend EC3 for this timeout condition.	How long are you willing to let a client hang waiting for a response? How long are you willing to let a thread in a servant (region) be tied up working on a response before concluding that the request has taken too long? If you have multiple application threads in the servant (region), all of them will be terminated when only one of them times out. This loss of work might make you want to allow these time outs to occur less frequently.
`ConnectionKeepAliveTimeout` None. All the other timers relate to work processing, whereas this one relates to what happens when there is no work.	None.	How much time passes between requests vs. how much does it cost to establish a new session. You would want to keep idle sessions around for a while to avoid the startup cost of a new session, but don't want to keep them forever as resource usage accumulation will eventually be a problem.
`Request Timeout (ORB Service)` None. This variable is a client-side timeout, and IIOP only.	None, other than to observe the timeouts occuring on the client side.	How long are you willing to let the client wait?
`ORB listener keep alive` `ORB SSL listener keep alive` None. These variables relate to session activity during idle periods and only for IIOP, so these timers do not interact with the ConnectionKeepAliveTimeout timer.	You should read TCP/IP APAR PQ18618 for information about the SOCK_TCP_KEEPALIVE values and their consequences.	Is it useful to have idle sessions timeout? They normally don't which can consume resources. However, detecting a timeout requires network traffic between TCP/IP stacks. Creating traffic on otherwise idle sessions may have network consequences you don't want.
`Total Transaction Lifetime Timeout` This variable can be overridden by applications up to the maximum indicated by the Maximum Transaction Timeout variable, which limits the amount of time an application can set for its transactions to complete. Output timers also might cause work to time out, but the transaction timers and output timers are not aware of each other.	The controller issues message BBOT0003W to indicate a timeout condition, and terminates the servant (region) with abend EC3 reason codes 04130002 or 04130005.	How long are you willing to let a client hang waiting for a response? How long are you willing to let a thread in a servant (region) be tied up working on a response before concluding that the request has taken too long? If you have multiple application threads in the servant (region), all of them will be terminated when only one of them times out. This loss of work might make you want to allow these time-outs to occur less frequently.
`Maximum Transaction Timeout` If set, this variable limits the amount of time an application can set for its transactions to complete. If the Maximum Transaction Timeout variable is not set, application transactions are controlled by the time limit set on the Total Transaction Lifetime Timeout variable.	None.	Same considerations as for transaction_ defaultTimeout
`transaction_ recoveryTimeout` None	None.	Locks are held while one controller waits for other controllers that are required to resolve in-doubt transactions. How long can you afford to have these resources held?
`server_region_request_cputimeused_limit`	This behavior is not easily monitored, but the controller terminates a request when the specified cpu use time limit is reached.	How much of your CPU time are you willing to let a single application request consume before taking some action against that request? If you have multiple application threads in the servant, all of them are terminated if terminating this request means that the servant now has enough unresponsive threads for the controller to terminate the servant. The setting for the server_region_stalled_thread_threshold_percent property determines how many threads need to be unresponsive before the servant is terminated.
`server_region_stalled_thread _threshold_percent`	This behavior is not easily monitored, but the controller will terminate the servant with abend EC3 when the percentage of unresponsive threads meets this condition.	How long are you willing to let a client wait for a response? How long are you willing to let a thread in a servant be tied up working on a response before concluding that the request has taken too long? If you have multiple application threads in the servant, all of them are terminated when the controller terminates the servant because the percentage of unresponsive threads is reached. This loss of work might make you want to allow a larger percentage of request threads to become unresponsive before having the controller terminate the servant.