not reproxying alternate files

Jonathan Steinert hachi at
Fri Feb 29 22:33:48 UTC 2008

Eric Lambrecht wrote:
> hachi wrote:
>> Actually, I believe your bug is more complex than this.
>> I hope you aren't using this patch in production, because in normal 
>> operation the codepath of try_next is used, but use_reproxy_backend 
>> is not. This patch causes t/35-reproxy to hang on the test it uses to 
>> see if it fails from one url to the next, because it gets into an 
>> infinite loop when it hits the failing URI.
> Hrmm... I'm not sure what you mean by 'normal operation'. You mean 
> when perlbal isn't reproxying something? (which in our case that 
> wouldn't be bad, as those machines only reproxy content..)

Sorry, normal was as opposed to 'unqueued backend reproxy'

When a reproxy request comes in and there's no backend for it yet, the 
code path followed includes try_next (on failure) but 
use_reproxy_backend isn't touched at all.

Basically, the t/35-reproxy test goes into an infinite loop with this 
patch you supplied. So I think it's the wrong answer. What needs to be 
known is how the state can transition us into use_reproxy_backend at 
all. Which has to be either backends that are 'Keep-Alive' or when you 
exceed the maximum number of allowed reproxy backends, which results in 

Firstly though, need a way to test those two possibilities to see if I'm 
even on the right track... which I'll get back around to after I eat 
some lunch.

>> I'm writing a test for this, but I suspect it happens when all your 
>> reproxy backends are in use, and the reproxy requests start queueing. 
>> I'm not sure though yet.
> Let me know if I can assist. I'll spend a little more time on this.
> Eric...
>> hachi wrote:
>>> Thanks for catching this. Patch is being applied right now.
>>> I kept swearing that it was working fine, and the test I ran to 
>>> confirm this showed it working as well. I had 3+ URLS in the list 
>>> though, so that's why it was "working"
>>> Eric Lambrecht wrote:
>>>> We just noticed that our perlbal wasn't reproxying the alternate 
>>>> files we gave to it via X-REPROXY-URL when the first file was 
>>>> missing. We'd send this:
>>>>     X-REPROXY-URL:
>>>> If 'foo' didn't exist on the remote server, perlbal was returning a 
>>>> 503 response and not trying to get 'bar'.
>>>> It's basically because both try_next_uri and use_reproxy_backend 
>>>> shift items off the $ClientProxy->reproxy_uris array. The second 
>>>> choice was being shifted off before we got a chance to try it.
>>>> Funny that it took us 2 years to notice this...
>>>> Eric...
>>>> ---      2008-02-28 17:32:13.000000000 -0800
>>>> +++  2008-02-28 17:32:41.000000000 -0800
>>>> @@ -184,7 +184,6 @@
>>>>  sub try_next_uri {
>>>>      my Perlbal::ClientProxy $self = $_[0];
>>>> -    shift @{$self->{reproxy_uris}};
>>>>      $self->{currently_reproxying} = undef;
>>>>      $self->start_reproxy_uri();
>>>>  }

More information about the perlbal mailing list