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