not reproxying alternate files
Eric Lambrecht
eml at guba.com
Sat Mar 1 21:43:51 UTC 2008
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.
>
> 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.
I think I figured it out... instead of removing the 'shift' from
try_next_uri, I needed to remove the 'shift' from 'use_reproxy_backend'.
t/35-reproxy now passes for me.
I also realized I'm still at 1.52, so this patch may not apply directly
to the latest version..
Eric...
--- ClientProxy.pm.old 2008-03-01 13:37:32.000000000 -0800
+++ ClientProxy.pm 2008-03-01 13:35:41.000000000 -0800
@@ -234,7 +234,7 @@
my Perlbal::BackendHTTP $be = $_[1];
# get a URI
- my $datref = $self->{currently_reproxying} = shift
@{$self->{reproxy_uris}};
+ my $datref = $self->{currently_reproxying} =
${$self->{reproxy_uris}}[0];
unless (defined $datref) {
# return error and close the backend
$be->close('invalid_uris');
More information about the perlbal
mailing list