Forum Discussion
Wil_Schultz_101
Nimbostratus
NimbostratusReselect pool on status code 500 or above...
So we run some Tomcat servers, when we undeploy the server will send a 503 that states that the application is unavailable. I do have a check that looks for a static page every 5 seconds and fails at 16 seconds, however for that 16 second period people from the outside world see this 503 error.
I would like to set it up to where any status code above 500 reselects but I seem to have an order of operation problem. Maybe someone that i saner than I might have a suggestion?
Here is what I have so far:
when HTTP_RESPONSE {
if { [HTTP::status] > 499 }{
set ::hostfailed 1
log local0. "Setting up ::hostfailed."
}
}
when LB_SELECTED {
if { $::hostfailed == 1 } {
LB::detach
LB::reselect [LB::server pool]
log local0. "LB failed, re-load balancing to pool."
}
}
This irule fails because LB_SELECTED us called after HTTP_RESPONSE and ::hostfailed is not set.
- JRahm
Admin
Have you considered HTTP::retry? This requires at least 9.2.
Here's the wiki page, it has an example:
http://devcentral.f5.com/wiki/default.aspx/iRules/HTTP__retry.html Click here 
Andy_Herrman_22I'm pretty sure Selected happens before Response. The Selected event triggers when the member the request will be forwarded to is picked. No response can come until after that's done.
I'm guessing retry will work, but if not there are other HTTP related commands you can do. You could do a redirect, or even generate your own response within the iRule and send that (instead of the response from the server). I haven't done this so I don't really know how it would be done, but I do remember seeing iRules that did stuff like that.
Wil_Schultz_101I can verify that the select takes place before the response :-)- Looks good, but I'd change this:
to this:if {!($myretry >= 3) } {
just because your way turns my brain inside out...if {$myretry < 3} {
/deb 
ArieAltostratus
It looks like the iRule is detecting the 5xx properly, but the redirect seems to be in a loop (calling the same node) until the browser gives up.
I assume the redirect follows the first retry attempts (number of active nodes -1).
Any idea why it seems to pick the same node instead of the next one?- Are you saying you've tried this and are having issues? It sounds to me like it was working for the OP.
Colin - ArieThat's right. I copied the iRule from the post and made the suggested change.
iRule runs w/o problems until I create a 500 on the server (ColdFusion restart), at which point I get the error in the browser (redirecting in a way that will never complete).
Looks like it keeps selecting the same node.
BTW, we're on 9.4.3 Build 1.4 Final. - ArieI've plugged in the new version of the iRule, but I'm still getting the same results (infinite redirects). Seems to happen in the first part (HTTP::retry), not at the HTTP::redirect.
Is it possible that the LB method is responsible? The browser seems to be stuck to the same node. - Wil_Schultz_101what does /var/log/ltm say?
tail -f /var/log/ltm - ArieUnfortunately my access level does not allow me to utilize Big-Pipe. Would this information be logged in the log the GUI can access?
