Status: Verified
GOAL:
How to tune database startup timing parameters for the AdminServer
GOAL:
Time out limit (<max_wait> seconds) exceeded waiting for ACK. (9149)
GOAL:
Error registering with Admin Server. (8845)
FACT(s) (Environment):
Progress 9.1C
Progress 9.1D
Progress 9.1E
OpenEdge 10.x
FIX:
When the AdminServer has multiple databases set to autostart and the database fails to register with the AdminServer errors 9149 and 8845 are seen in the admserv.log file.
The timing variables described below should not be modified unless a need arises.
The timing variables are specified in a file (name=value format) and changing the AdminServer startup command to include the Java property setting "-DConfigToolTimings=<filename>" where <filename> is the name of the file where the <timingVar>=<valueInSeconds> settings are saved.
If AdminServer is being started by the "PROADSV" command, the Java property may be set by setting the JVMARGS environment variable.
For example: JVMARGS="-DConfigToolTimings=<filename> $JVMARGS"; export JVMARGS
The changes for the Windows platform should be done in the Windows registry.
Modify the registry key:
HKEY_LOCAL_MACHINE\Software\PSC\PROGRESS\<version>\JAVA
value of JVMARGS :
-ms8m "-DConfigToolTimings=C:\91d\stuff\timings.txt"
Timing Variables
----------------
Below are the names of the timing variables, their defined defaults, and a description of what the timing variables control.
DbStartupDelayMin=10
DbStartupDelay=5
It is possible at AdminServer start time/database plugin start time, that some database brokers (previously started through the Progress Explorer) are already running. At database plugin start time, Progress waits for these database brokers to re-register with the AdminServer's database plugin.
These parameters control how long the database plugin will wait before checking if any more registrations between database objects and their _mprosrv processes have occurred. At a minimum, the database plugin will wait the number of DbStartupDelayMin seconds for any registrations to occur. If no registrations have occurred, no more waits for subsequent registrations are done.
If any registrations have occurred, then the database plugin polls every DbStartupDelay seconds until no more registrations are received between polls.
WTCStartingMin=300
WTCStarting=120
Before a database starts, it is in the Idle state. During database starts, databases transition from the idle state -> starting state -> the initializing state -> the running state.
These parameters control how long the database plugin will wait for a database object to transition from the idle state to the start state. A successful transition to the start state means that the database object has established initial communication between itself and the _mprosrv process it controls. The starting state timers are terminated upon successful state transition, or in worse case, upon the timer expiration. If the timer expires, the database remains in the idle state.
At minimum, the database will wait up to WTCStartingMin seconds for a successful state transition. If multiple databases are being autostarted (numberOfAutostarts) at database plugin startup, the time required to make the state transition can be longer. As a result, the individual databases will wait WTCStarting*numberOfAutostarts or WTCStartingMin seconds, which ever is greater.
WTCInitializingMin=300
WTCInitializing=120
Once a database object has established communication between itself and its _mprosrv process, some validation must occur before the database object can transition from the starting state -> initializing state. These timers control how long this validation process can take.
Timers are terminated immediately upon successful state transition, or in worse case, when the timer expires. If the timer expires, the database object is forced back to the idle state.
At minimum, the database object will wait up to WTCInitializingMin seconds for a successful state transition. If multiple databases are being autos.tarted (numberOfAutostarts) at database plugin startup, the time required to make the state transition can be longer. As a result, the individual databases will wait WTCInitialing*numberOfAutostarts or WTCInitialingMin seconds, which ever is greater.
WTCShuttingDownMin=300
WTCShuttingDown=120
Before a database is shut down, it is in the running state. During database shut down, databases transition from the running state -> shutting down state -> idle state. These timers control how long the shutdown process can take before the database is assumed crashed.
Timers are terminated immediately upon successful state transition, or in worse case, when the timer expires. If the timer expires, the database is assumed crashed and the database object is forced back to the idle state.
At minimum, the database object will wait up to WTCShuttingDownMin seconds for a successful state transition. If multiple databases are being autostarted (numberOfAutostarts) at database plugin startup, the time required to make the state transition can be longer. As a result, the individual databases will wait WTCShuttingDown*numberOfAutostarts or WTCShuttingDownMin seconds, which ever is greater.
PollServerGroup=11
Database objects may be configured to start auxiliary processes such as after image processes, before image processes, watch dogs, and after page writers, and may be configured to start secondary brokers.
This timer dictates the poll interval in seconds that the auxiliary and secondary broker processes will be polled to determine when they are running. Polling ends when the processes are either running are when they have failed to start.
In addition to this, to disable all timeout values for databases, JVMARGS should include "-DBypassDatabaseTiming=true" on the AdminServer startup line in proadsv, or in the Windows registry under
My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\PSC\PROGRESS\<Progress version>\JAVA
Depending on the version that you use the JVMARGS may not exit by default. Create one new string value if it not existed.
This will bypass all database timers, i.e. if a database takes 3 days to startup we the AdminServer will patiently wait for it.
If the database starts, or gets an error, the AdminServer will stop waiting for it since the database has in some way responded. .