Managing servers timeouts through iRules

There are a number of conditions that can happen with any given application server:

1. The server reports a 40x or 50x error in response to a request, generally when the request isn't acceptable or some part of the application itself has failed.

    

2. The server fails completely in which there is no response at all.

    

3. The server takes too long to respond, but is otherwise (mostly) functional.

    

The HTTP::retry command works in the context of an HTTP response, so you'd have to have a response, like a 40x or 50x from scenario 1 above to be able to use it.

Assuming you have a good monitor attached to the pool, then scenario 2 above might be more easily be handled with LB events and commands, like perhaps the examples in the LB::reselect wiki article:

when CLIENT_ACCEPTED {
    set def_pool [LB::server pool]
    set lb_fails 0
}
when LB_FAILED {
    if { $lb_fails < [active_members $def_pool] } {
        LB::mode rr
        LB::reselect pool $def_pool
    } else {
        ... add failure logic here
    }
    incr lb_fails
}

When a second server is selected in the above code, the request will be automatically retried. The 3rd scenario is a little more complex and might rely on some arbitrary timing mechanism to achieve, but then if your monitor is configured appropriately, a slow response to a monitor request should take the member out of the pool, and then be treated just like scenario 2.

Kevin,

    thanks for your answer. 

    Regarding the 3rd scenario, the inband monitor could be useful?

Thanks and Best regards

Sergio

Regarding the 3rd scenario, the inband monitor could be useful?

i think if you want to take some action on the current (long response) connection, inband monitor might not be useful.

there is an example in after command wiki to send response (e.g. redirect) if server does not respond in specified time. not sure if it is useful in your case.

after

Thanks Kevin and Nitass.

I have another question:

What is normally used to avoid showing an empty (or error) page to a user when a server is down but the monitor still does not mark it as down?

This is what I need to cover, so I thought on manage the server timeout, but maybe there is another better solution.

I will appreciate your comments,

Thanks and Best regards

This again depends on what the error is.

If the server is actually responding, but it's an error response (ie. 40x or 50x), then you can pretty easily trap that in an HTTP_RESPONSE event and modify the response to the user, or adjust your HTTP monitor(s) to catch these types of responses.

If the server is just down, and it doesn't respond at all, then hopefully the monitor would have already taken this guy out of the pool. If you're worried about it dying mid-session, then you can potentially look at timing responses or using an inband monitor.