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.