Timeouts are an important aspect of server products. Timeouts limit the amount of processing time for requests and limit the amount of time a request stays in a queue. This is important for performance. It also keeps your site running if inappropriate requests are made.
Timeouts in ArcIMS happen in two places: within the ArcIMS Application Server and within the Spatial Servers. The Application Server timeouts can be changed in AppServer.properties. The Spatial Server timeouts can be changed in the Spatial Server configuration files.
A timeout occurs in two cases:
When using the Internet, the default of 60 seconds is a long time. Many users will give up if a request takes this long. If you find you need to raise this limit because one or more services is responding slowly on a regular basis, you should review the Optimizing ArcIMS services checklist to make your service as efficient as possible.
Some common use cases where the timeout may be exceeded are:
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:
The extendedTimeout value should be tuned to synchronize with the maximum time that the Spatial Server requires to get itself set up with the data sources and related tasks in setting up a new service. Some common use cases where the extendedTimeout may be exceeded are:
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. A timeout value of 0 is interpreted as infinity.
When a timeout, extendedTimeout, or metadataPublishTimeout is reached, the Spatial Server instance where the timeout occurred is no longer available until it can be recovered. When the Application Server cycles to the timed out Spatial Server instance, it is marked 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 time in seconds before the Application Server pings the Spatial Server. For more details about this timeout, see Setting an interval to keep firewalls open.
When a request times out based on the value of timeout, the Application Server sends a message to interrupt the Spatial Server. By default, the Application Server waits 15 seconds after the request times out. This gives the Spatial Server an opportunity to finish processing the request without intervention, and the Application Server does not need to go through the procedure of restarting a Spatial Server instance.
When the Application Server sends a message to the Spatial Server to interrupt a request, only the instance the request is running on gets restarted. If the instance cannot be reconnected, the Application Server will send a message to restart the entire Spatial Server process. This restart can be time consuming since all services must be added on each instance. It is recommended not to change this value unless the entire Spatial Server is restarted often during the reconnection process.
When the Application Server detects a network dip, ArcIMS Monitor waits for this time interval before reconnecting Spatial Servers. A network dip occurs when the network goes down for a small period of time and comes back up. ArcIMS Monitor periodically pings the Application Server. A dip is detected when a ping succeeds after failed ping(s) and in the meantime the Application Server has not restarted. Following a network dip and the networkDipReconnectWait time period, ArcIMS Monitor starts the reconnection process. Reconnection is done to repair bad network connections between the Application Server and Spatial Servers and to avoid replacement of Spatial Servers, which takes more time.
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.
Windows: <ArcGIS Installation Directory>\ArcIMS\AppServer
UNIX and Linux: $AIMSHOME/Middleware/Application_Server
Windows: <ArcGIS Installation Directory>\ArcIMS\Server\etc
UNIX and Linux: $AIMSHOME/etc
To change the ArcSDE timeout attribute for all services:
To change the connectioncheckinterval:
ArcMap Image Services
Image, Feature, and Metadata Services