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.

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 stating 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 Spatial Server to stop processing the request, and it sends a message to the client that the request timed out.

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:

• You have too few Spatial Server instances for the number of requests. In this case, requests get queued by the Application Server. If the queue gets too large, requests drop out due to the timeout.
• You are using an ArcMap Image Service. Open the map file (*.mxd) in ArcMap. If you find that the draw time is slow in ArcMap, it will be at least as slow in ArcIMS.
• Your users are requesting very large images. Sometimes large images are requested for plotting or printing. These large images can take a very long time to generate.

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.

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:

• Your service has many layers. It may take more time than allotted for the Spatial Server to process every layer.
• You are using an ArcMap Image Service. This service type takes longer compared to other service types.

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. A timeout value of 0 is interpreted as infinity.

Application Server: recoveryTimeout=300

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.

Application Server: serverConnectionPingInterval=1800

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.

Application Server: waitAfterInterrupt=15

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.

Application Server: waitAfterReconnect=5

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.

networkDipReconnectWait=30

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.

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.

Changing the Application Server timeouts

Changing the Spatial Server timeouts