Forum Discussion

Tom_Bortels_112's avatar
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 /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








7 Replies

  • 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.
  • 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 80
       log local0. "\[LB::server\]: [LB::server]"

    < HTTP_REQUEST>: [LB::server]: ubuntu_external_http_pool 0

    < HTTP_REQUEST>: [LB::server]: 80

  • 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
    Historic F5 Account


    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.


  • 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?