not reproxying alternate files

[Jonathan Steinert]

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 
queueing.

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: http://127.0.0.1/foo http://127.0.0.1/bar
>>>>
>>>> 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...
>>>>
>>>>
>>>> --- ClientProxy.pm      2008-02-28 17:32:13.000000000 -0800
>>>> +++ ClientProxy.pm.new  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();
>>>>  }
>>>
>>
>