Forum Discussion

Tom_Bortels_112's avatar
Tom_Bortels_112
Icon for Nimbostratus rankNimbostratus
Dec 13, 2010

LB::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

 

 

 

 

 

 

 

application delivery
dev
devops
iRules
  • Tom_Bortels_112's avatar
    Tom_Bortels_112
    Icon for Nimbostratus rankNimbostratus
    Dec 14, 2010
    Yes - 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.
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 14, 2010
    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_112's avatar
    Tom_Bortels_112
    Icon for Nimbostratus rankNimbostratus
    Dec 14, 2010
    That'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
  • Michael_Voight_'s avatar
    Michael_Voight_
    Historic F5 Account
    Dec 17, 2010
    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.

     

  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Dec 17, 2010
    I 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