Change in proxying behavior after 1st "failed" health monitor probe?
A simple question about health monitors. I understand how the interval and timeout work together to mark a server down. But, is there any change in the balancer's processing of an incoming request after the very first "failed" monitor? For example, if the interval is 5s, and the timeout is 16s, after a health monitor attempt fails to respond within 5 seconds, the server won't be marked down yet - but does the balancer stop sending new connection attempts, ones with no persistence yet set, to that server, on the premise that it's in an uncertain state, potentially heading toward being marked "down"? I believe the answer is "no", that alertd doesn't track individual attempts, but instead acts like a simple countdown state machine, with every successful monitoring attempt resetting the machine to the initial state. If so, is there any straightforward way to achieve that behavior - preventing new connections from going to a server if the last health probe has not responded before the next one is issued, while still leaving existing connections (those with a persistence cookie, or persistence table entry) to "stick" with the server until it meets the timeout condition and is marked as down? The rationale for wanting to do that is if establishing a new session state on a new server is a very punitive or disruptive event - so for an existing user connection, we don't want to transfer them to a different server too easily, but for a new connection, we want to minimize the chance of failure by not sending them to a server that may have failed. Thank you!