differentiate between ArcIMS timeouts

Summary

** Internal Publish Only! This article may contain information that is not intended for external circulation. **

The information here is a detailed description of the timeouts, especially for recoveryTimeout. Because the implementation could change at any time, the recoveryTimeout details should not be included in a public KB article.++++++++++++++++++++++++++++++Application Server: timeout=60
A timeout occurs in two cases: 1. The Application Server was not able to allocate a Spatial Server instance because all the instances are busy. After the specified time period, the request is removed from the queue, and a message is sent to the client that the server is unavailable. 2. The Application Server has waited for a response from the Spatial Server for the specified time period. The stopwatch for this period starts as soon as the Application Server sends the request to the Spatial Server. Once the time period expires, the Application Server sends a message to the client that the request timed out. (Note: At ArcIMS 9.2, the AppServer will also send a message to the Spatial Server to timeout as well).++++++++++++++++++++++
Application Server: extendedTimeout=300
The time period in seconds the Application Server waits on a Spatial Server to start or refresh a service. The extendedTimeout is used in two scenarios:1. When services are started using an administration tool. During administration, if a service reaches the extendedTimeout on the first Spatial Server instance, the Application Server will not attempt to start the service on any other instances within the Virtual Server. If a service fails on the second or higher instance, the service will be removed from all instances. In both cases, a "failed to add/change service" message is returned. Services already running are not affected. During this administration process, the Virtual Server is not available for handling requests. 2. When services are started during restoration such as when ArcIMS is being restarted. The Application Server sends the start service request to all Spatial Server instances within the Virtual Server. If the add service request fails on an instance, the instance is marked as bad, and all services on that instance become unavailable. However, other restored instances in the same Virtual Server will continue to start services added to them. As with administration, the Virtual Server is not available for handling requests during restoration. ++++++++++++++++++++++
Application Server: metadataPublishTimeout=0
The time period in seconds that the ArcIMS Application Server waits on an ArcIMS Spatial Server to respond to requests for publishing metadata documents or administering the metadata service. Timeout value 0 is interpreted as infinity. ++++++++++++++++++++++
Application Server: recoveryTimeout=300
When a timeout, extendedTimeout, or metadataPublishTimeout is reached, the Spatial Server instance is marked as bad. The Application Server will continue to process requests. When the Application Server cycles to the bad Spatial Server instance, the Application Server marks the instance for recovery. On a busy site, an instance might be marked for recovery quickly. On a lightly used site, it may take minutes or hours before the instance is marked for recovery.Once the Spatial Server instance is marked for recovery, the recoveryTimeout stopwatch starts. During this time, if the Spatial Server instance can repair itself, it is removed from recovery mode, and requests can be sent to it again. If after the specified time period the Spatial Server instance has not responded, the Application Server sends requests to reset the instance. If this is not successful, after the specified time period for recoveryTimeout, the Application Server restarts the entire Spatial Server process. Therefore, the maximum time the recovery process takes is two times the number of seconds specified for recoveryTimeout. ++++++++++++++++++++++
The following sequence of Application Server timeouts occurs once a request times out.1. A request times out based on the timeout, extendedTimeout, or metadataPublishTimeout values. 2. The Spatial Server instance is marked as bad. 3. When the Application Server cycles to the Spatial Server instance, and it is still marked as bad, the instance is sent into recovery mode. 4. The Spatial Server instance may recover before the recoveryTimeout is reached. In this case, the instance is removed from recovery mode. 5. If the recoveryTimeout is reached, the Application Server attempts to restart the Spatial Server instance. 6. If the Spatial Server instance does not respond after the period specified in the recoveryTimeout, the Spatial Server process is restarted. This means that all instances belonging to a Spatial Server are restarted, not just the original bad instance. 7. The Application Server restores the Spatial Server. During the time it takes for all the services to start, all instances within the Virtual Server group are unavailable. 8. After the services are started, the Virtual Server is ready to receive requests. ++++++++++++++++++++++
Spatial Server: ArcSDE timeout="15"
The ArcSDE timeout is a Spatial Server timeout. It is the maximum number of seconds for an ArcSDE connection to be made when an ArcIMS service is starting or when an ArcSDE connection must be restored after a service is already running. ++++++++++++++++++++++
Spatial Server: ArcSDE connectioncheckinterval="300"
The connectioncheckinterval defines the time interval between attempts to reconnect to ArcSDE when an ArcSDE server is unavailable. Without a connection check interval, the Spatial Server tries to connect to ArcSDE for each layer. This can be time consuming since each request to ArcSDE can take 15 seconds (the value for the ArcSDE timeout). With the connection check interval in place, the Spatial Server tries to connect to the first layer as always. If the connection fails, no additional attempts are made to reconnect to ArcSDE for the time defined in the interval. The amount of time spent on trying to start a service or process a request decreases significantly, and the Spatial Servers become available once again to process other requests.

Procedure