not reproxying alternate files

[hachi]

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.

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.

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();
>>  }
>