Downtime Announcement: Please note the SAP Community Wiki will be unavailable due to a system upgrade on Thursday, September 24th between 6 and 7 AM CEST
Skip to end of metadata
Go to start of metadata

 

Purpose

Assist with the timeout settings of the Web Dispatcher, taking into account its backend system(s) – ICM and other timeouts.

Overview 

This page shows how to setup the timeouts at the Web Dispatcher and its backend system(s), in order to avoid unexpected timeout related issues, like the Web Dispatcher raising a timeout before the backend. This could cause the user to open multiple sessions, as the user will receive a timeout (and will have to logon again) despite the session is still active at the backend.

TIMEOUT argument

There are two timeouts that can be set at the icm/server_port_<xx> parameter. If these are not set, both will use the value of the parameter icm/keep_alive_timeout (default: 60 seconds).

The first timeout is defined by the TIMEOUT argument. This timeout controls how much time the TCP/IP connection can remain open after the request has been processed successfully. For example, after the Web Dispatcher has sent the response to the client (e.g., internet browser from the end user computer) it will keep the TCP/IP connection open for up to TIMEOUT seconds.

This avoids the need for the browser to setup a new network connection with the Web Dispatcher. This usually does not cause any issues and the default value can be used. This is also valid for the ICM (backend system).

PROCTIMEOUT argument

This is the second possible timeout that can be set.

As the name suggests, this is the "processing timeout". In other words, how much time will the Web Dispatcher wait for the backend to send the response. This means that once the Web Dispatcher has sent the request to the backend, it will wait for up to PROCTIMEOUT seconds for the response. If the response is not received, the Web Dispatcher closes the connection to the backend and returns a “500 timeout error” similar to the picture below.

 


 

This timeout works in the same way for the ICM, where the ICM will be waiting for the ABAP/Java to process the request and provide the response.

Other related parameters (ABAP backend)

At the (ABAP) backend system, additional parameters/settings should be considered.

rdisp/max_wprun_time

This defines the maximum amount of time that a dialog work process (which will be handling HTTP requests) can continuously process a request, without interruption (e.g., a long running report). Therefore, this parameter should not be lower than PROCTIMEOUT;

rdisp/plugin_auto_logout

This defines the maximum amount of time that the application session can remain idle (e.g., after the response has been sent to the end user, how much time the session will remain active, waiting for the next request);

http/security_session_timeout

As of kernel 720, this is a security session timeout parameter (SAP note 1899896 and 1322944). It should be set to 200 seconds higher than rdisp/plugin_auto_logout (SAP KBA 1914112).
When rdisp/plugin_auto_logout < http/security_session_timeout, the user session should time out first per rdisp/plugin_auto_logout. However, the security session cookie is not cleared because the security session timeout is not expired. Therefore, the user doesn’t need to perform logon to access the application even though the application has timed out. Then the user will experience that all application contexts are lost (and he has to type in the data, again) but that he's not prompted to logon, again.
Note: The TIMEOUT in ICM parameter icm/server_port_<xx> is keep alive timeout, which specifies how long an HTTP connection can stay open for reuse by new requests/responses after a request/response cycle. This is for performance improvement and has nothing to do with the backend session timeout.

4) Settings at the service definition, at the transaction SICF, as well as application specific settings should be considered as well.

Summary

Considering the above, it makes sense to set both TIMEOUT and PROCTIMEOUT settings of the icm/server_port_<xx> parameters to the same value at the Web Dispatcher and at the backend instances (ICM).

Thus, if the parameter "icm/server_port_X = PORT=…, PROT=HTTP, PROCTIMEOUT=600" is set at the Web Dispatcher, the PROCTIMEOUT of the HTTP port at the backend instances should be set to 600 as well.

In addition, "rdisp/max_wprun_time" should be set to at least 600 (same value as PROCTIMEOUT).

Finally, "http/security_session_timeout" should be set to 200 seconds more than "rdisp/plugin_auto_logout".

  • No labels