Forum Discussion
Tom_Bortels_112
Nimbostratus
NimbostratusLB::Server not seeing pool command results?
I just ran across an odd behavior, thought I'd share in case it hits someone else...
I have two farms - "webha" for static pages, and "webha-cgi" for cgi scripting. I'm looking at the HTTP::path for things like ".cgi" and sending those to the cgi farm. It seems to be working - but I get weird results back from LB::server.
Specifically - sometimes, when I do this (I set $default_pool in CONNECTION_ACCEPT):
now route the traffic to the appropriate pool
log local0. "Before switch, pool is [LB::server pool] (default $default_pool) for [HTTP::host]"
set ourmatch "nothing"
switch -glob [string tolower [HTTP::path]] {
/cgi-bin/* { set ourmatch "cgi-bin" }
*.cgi { set ourmatch "cgi" }
}
if {$ourmatch ne "nothing"} { set newpool $default_pool-cgi }
else { set newpool $default_pool }
pool $newpool
log local0. "matched $ourmatch - pool is [LB::server pool] (newpool is $newpool) for [HTTP::host] [HTTP::uri]"
Sometimes - 1 out of 50 maybe - I get the old pool, even though we've just set a new pool. Specifically, we'll do "pool webha" and the followup log says "pool is webha-cgi" - but when I go look, the request *actually* did land on the webha pool servers.
Dec 13 13:58:45 local/tmm info tmm[5290]: Rule webha_app_director : matched nothing - pool is webha-cgi (newpool is webha) for www.not-the-domain.com /Admin/admin.css
So - "LB::server pool" is giving back the wrong info, in some cases, where it's just been set with a new pool. The new pool actually *works* - this appears to be a reporting issue with LB::server. If I used that to do work with, it would cause bugs, presumably...
Anyway - thought I'd share, in case someone else is searching for this sort of behavior. If anyone can explain how this could happen, I'm all ears; I'd think the update done by "pool" would be atomic, and any followup calls to LB::server would give back the new pool - but maybe we're caching results or something? Is a puzzlement.
-- Tom Bortels, reluctant iRules d00d
- Chris_Miller
Altostratus
From which event is this rule being run? HTTP_REQUEST? 
Tom_Bortels_112Yes - the code above is in HTTP_REQUEST. I'm sorry - that was unclear. I set default_host in the CONNECTION_ACCEPT, then the rest of the code is in HTTP_REQUEST. That's not the only code (I have to play some games with cookies to support a legacy application we have here), but that's the portion that messes with the pool.- Edited: Please see my updated note later...
hooleylistCirrostratus
I didn't think LB::server was cached like most HTTP:: commands are. In a simple test, it looks like the correct values are logged before and after a change. And it doesn't make much sense if LB::server returns correct results a majority of the time.when HTTP_REQUEST { log local0. "\[LB::server\]: [LB::server]" node 1.1.1.1 80 log local0. "\[LB::server\]: [LB::server]" }
< HTTP_REQUEST>: [LB::server]: ubuntu_external_http_pool 0
< HTTP_REQUEST>: [LB::server]: 1.1.1.1 80
Aaron- Tom_Bortels_112That's what was throwing me - I can confirm the pool got set right (because I see apache tracks on the correct destination server) - and *usually* [LB::server pool] gave me the new value... just sometimes not. Intermittent.
Unexpected but consistent just means I don't understand the universe yet. Intermittent scares me.
-- Tom - http://devcentral.f5.com/wiki/default.aspx/iRules/LB__reselect.html
This was just added to the description, as the result of a support case: "Note that the reselect may not happen immediately; it may wait until the current iRule event is completely finished executing"
This means checking the value of lb::server within the event may show the previous server. - hooleylistI think the original poster's iRule was logging the value in HTTP_REQUEST. Would that info be relevant if no reselection was done by LB::reselect or a pool action on service down setting?
Aaron
