It's important to differentiate between:
- "idle" (ie connected but inactive) and
- "dead" (ie no longer connected, but still in the database shared memory).
An OpenEdge database cannot detect a dead remote client connections, instead, it relies on the network protocol to notify the database that a remote user has died or disconnected. Refer to Article 000080089, How to configure the Operating System TCP KEEPALIVE
This Article discusses a method of controlling remote ABL client sessions through the assumption that if the connection has exceeded x-time of inactivity to the database, then the client is probably either (a) idle (b) hanging or (c) terminated abnormally (crashed).
The ClientTimeOut parameter allows the database remote server process to determine whether a remote ABL client has been inactive for a specified period of time and if so, the remote server disconnects that remote client and backs out any related active transaction releasing associated locks/latches it may be holding at the time. Client "inactivity" is treated as the client not accessing the database for a specified period of time.
On Windows the ClientTimeOut parameter is a REGISTRY key entry only, where the value is in minutes.
As of this writing (OpenEdge 11.7), there is no Progress equivalent of ClientTimeOut on U/Linux. This is purely a windows function to manage idle connections.
ClientTimeOut functionality was broken in Progress 9.1B/9.1C and fixed in Progress 9.1D02.
If a client remotely connects to two or more databases and currently works only with one of them, the client will be stopped as "inactive" in other database(s) and the following will appear in the database log file:
Client <num> was inactive for more than <num> minutes (4435).
If the databases are started/managed by the AdminServer, since the AdminServer does not read the registry but gets it's information from the properties files and ClientTimeOut is not a standard parameter, it cannot be added to the "Other Arguments" or as an entry in the conmgr.properties file, because it is expected only as a registry entry on the Database Server machine.
The ClientTimeOut parameter only manages remote ABL connections. If batch processes are run as shared memory connections they will not be terminated. Instead, the WatchDog functionality will clean up dead shared memory connections but not idle connections.
Steps:
The parameter uses the following syntax:
ClientTimeOut=n
Where n is the number of minutes a client can be idle before the remote server disconnects it.
The ClientTimeOut parameter needs to be added to the registry of the Database Server machine as a "String Value", in one of the following keys. By default this string will not exist and needs to be created.
HKEY_CURRENT_USER\SOFTWARE\PSC\PROGRESS\<VERSION>\STARTUP
or
HKEY_LOCAL_MACHINE\SOFTWARE\PSC\PROGRESS\<VERSION>\STARTUP
Where <version> is the current version (e.g. 11.3).
1) Create a "String Value" with the CamelCaps name: ClientTimeOut
2) Assign a value to the ClientTimeOut String which is a number <n> that represents the number of minutes to wait before disconnecting an idle client (e.g. 3 minutes = "3" as the value for the string)
Alternate methods include:
- Firewall settings that terminates idle TCP connections.
- Application-side triggers that cause the application session to terminate after a delay if the user does not interact with it.
