Forum Discussion
NimbostratusWhen 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?
3 Replies
Mohamed_LrhaziAltocumulus
Very interesting question. I hope you have a case open with Support too.
I was reading the wiki page on LB_FAILED which I found very informative. I never noticed the "Available Commands:" section on that wiki.. is it supposed to be exhaustive?
https://devcentral.f5.com/wiki/iRules.lb_failed.ashx
Thanks,
Mohamed.
Chris_Phillipsno one have an answer to this?
What_Lies_Bene1Cirrostratus
Doesn't seem so. Any chance you could post your rule code so we can check there's nothing in there that might be causing this?
BTW, has this only happened once?
Also, have you tried using OneConnect, it tends to spookily fix things like this.
