> #### Agent (Server) Unavailable rule

> The list of available rules includes the following:

> - Agent Unavailable rule for a Transaction Server — This rule monitors an agent's processing state to determine the agent's availability to service requests.
> - Server Unavailable rule for an AppServer — This rule measures a server's processing state to determine the server's availability to service requests.

> For either an agent or a server, this condition can indicate a failed, hung, or runaway process.

> Note: Unlike other Fathom rules, the WS_Agent Unavailable rule and the WS_Server Unavailable rule monitor the state of either an agent or server, rather than the data each resource collects.

> ##### Accessing the Agent (Server) Unavailable page

> The Agent Unavailable page is accessible from the WebSpeed Available Rules page; the Server Unavailable page is accessible from the AppServer Available Rules page. On each page, you specify an integer to identify the threshold number of polls at which point you want to be alerted that the agent (or server) has been unavailable. You can also set other alert and action criteria.

> ##### WebSpeed agent example

> A user, initiating a customer order query in WebSpeed through a browser, 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, expecting a quick display of a results set, 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. Impatient due to the time he is waiting, the user 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 display.

> Unknowingly, each time the user clicks the Submit button it 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 agent(s) are unavailable to service new client requests, potentially impacting application performance and throughput. This performance degradation can easily be compounded by the drain that 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 thwart the potential for performance problems to escalate.

> ##### AppServer server example

> An AppServer Server might be stuck in an unavailable state due to either a startup fault or an application-level fault. The Server Unavailable rule is designed to alert you to a server that is unavailable due to these types of potential situations.

> Note: This rule and its implications as described apply only to stateless and statefree implementations of an AppServer. This rule does not apply to state aware or state reset implementations.

Copyright © 2004 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095