When does LB_FAiILED fire in relation to reselect tries settings?
Howdy,
I've a basic iRule on a SOAP service which gives back a SOAP Fault message on LB_FAILED, as there's no inherit functionality like this outside of a fallback redirect which isn't appropriate for a web service. It just does a simple HTTP::respond and nothing else
On the pool it balances to, we have the Reselect Tries set to 3.
The other day we had a TCL error in our logs stating that the HTTP::respond was illegal after a response had already been sent tot he client. This was then followed 4 seconds later by sod rebooting everything, which is somethign of an aside for now...
There is only this one rule on the virtual, no fallback on the http profile or anything, just the default http profile itself. So the only way I can see that a response had been sent before this LB_FAILED response is if LB_FAILED had already fired.
F5 PS have previously "confirmed" that the LB_FAILED will fire after the reselect tries are exhausted, so this scenario should not be possible, but then even if that's not so, shouldn't intercepting and HTTP::responding in an LB_FAILED stop subsequent retries and further LB_FAILED events occuring?