Setting up a task: Processing Response
- How to handle returns: For most tasks you will want to use the "Any connection is a success" setup. The connection routine will perform standard validation on the returns. If you are checking a web site cgi script, or database, then you will want to validate the return by checking for a phrase. Otherwise even an error return from the web server will be considered a success.
- Check Line By Line: If you are checking an open ended stream in the GenericTCP server, or are validating content on a web server that forces to a persistent connection you must select this and scan the return one line at a time. The task will continue to listen to the stream until it either receives the match, reaches the maximum number of lines or times out.
- Perform No Action if: If WB is connecting through a router or gateway, if the gateway goes down then the other tasks will fail as well, so it makes no sense to perform a reboot of the web server when it is the gateway that is down. If you select this and the gateway task in the popup then it will behave in the following way.
If an action is called for then the task will look to see if the dependant task is already offline. If so then no action will be taken. If the dependant task is online, then a check on the dependant server will be performed. If the return from this is good, meaning the gateway is up, then the action will be performed. If the dependant task fails then no action will be taken.
- Seconds to wait for response This is the timeout to wait for a connection. If no connection is made by the time this timer runs out then a failure is logged. In the case of the web task then just getting a connection is not enough, you must have gotten the data from the web server by the time this runs out. This defaults to 15 seconds but may need to be extended for very busy servers or if WB is running on a very slow server.
- Failures Before Action sometimes a web server, or other server, will refuse a single connection and this doesn't necessarily mean that the server is down. You can set this number to a count of failures in a row before an action is performed.
- Minutes Extra After Action If your action is to restart the server, this can add significantly to the amount of time before the server will be up again. Especially if you are using a powerkey and power off the server. It must reboot and go through the whole disk checking routine before coming up again. So you can add extra time after an action before it starts checking again. For example if your web server check interval is normally 5 minutes and it is restarted, it might take 10 minutes to come back up. If you do not set this value then your server will be stuck in a restart, no response, restart... loop.
- Seconds wait between failures If you have multiple failures before action selected then this setting allows you to select the amount of time to wait after a failure before trying again.
Previous Page | Main Index | Next Page (setting up a powerkey)