A user initiates a customer order query in WebSpeed through a browser and accidently enters a date range for one year (requesting the processing of 52 weeks' worth of data records) rather than the date range for one week (requesting 1 week worth of data records). The user expects a quick display of a results set and is unaware that the agent is tied up for an unknown period of time attempting to process more than 2,000,000 records associated with the year. The user becomes impatient with the wait time and begins clicking the Submit button over and over, hoping for some indication that the job has been submitted and the results set is ready for viewing.

Unbeknownst to the user, each click of the Submit button causes the allocation of a new agent to service the request. This allocation might initiate the spawning of a new agent process. While this is occurring, the existing agents, processing the previous query requests, are unaware that the connection to the requesting client's browser page has been lost. These agents continue to consume resources as they process a request with no destination. If the request is long-running, as defined by this example, the agents are unavailable to service new client requests. This can impact application performance and throughput. The performance degradation can easily be compounded by the drain these agents place on other resources such as CPU, memory, and databases.

As this example illustrates, you can use the Agent Unavailable rule as designed to help call attention to potential processing difficulties as soon as possible, and to prevent performance problems from escalating.