perlbal(reverse proxy role) timing out for slow 'reproxy' backends

[dormando]

Thanks for the test case!

I won't have time to look into this for a while, so if someone else on 
the list can help out, please do!

-Dormando

Hemant Bist wrote:
> Hi, I am able to reproduce this with a simple cgi script that keeps on 
> writing to stdout. (Attached). The error happens within 10 sec of the 
> max_idle_timeout. I see the following messages  when I set the DEBUG env 
> variables.
> 
> Backend Perlbal::BackendHTTP=ARRAY(0x87a13a4) is readable!
> write(Perlbal::ClientProxy=ARRAY(0x87a0a08), <886>"
> Some  Random dat...") from (Perlbal::BackendHTTP, 
> /usr/share/perl5/Perlbal/BackendHTTP.pm, 562)
> Client (Perlbal::ClientProxy=ARRAY(0x87a0a08)) closing backend 
> (Perlbal::BackendHTTP=ARRAY(0x87a13a4))
> 
> 
> ====Sample run with timeout set to 60 sec with perbal running on port 
> 8090=======
> time  wget http://192.168.1.52:8090/blodio/forever_internal_redirect.modperl
> --14:03:17--  
> http://192.168.1.52:8090/blodio/forever_internal_redirect.modperl 
> <http://192.168.1.52:8090/blodio/forever_internal_redirect.modperl>
>            => `forever_internal_redirect.modperl.1'
> Connecting to 192.168.1.52:8090 <http://192.168.1.52:8090>... connected.
> HTTP request sent, awaiting response... 200 OK
> Length: unspecified [text/plain]
> 
>     [                                                  <=>        ] 
> 55,818       771.43B/s            
> 
> 14:04:24 (856.85 B/s) - `forever_internal_redirect.modperl.1' saved [55818]
> 
> 
> real    1m7.116s
> user    0m0.012s
> sys     0m0.012s
> 
> HB
> 
> On 9/17/07, *dormando* <dormando at rydia.net <mailto:dormando at rydia.net>> 
> wrote:
> 
>     Okay,
> 
>     I missed it on my first read through that area. Adjusting that variable
>     should fix it for you. The latest SVN will work better since it's
>     configurable.
> 
>     BackendHTTP.pm does the "client writing" of a response. Thinking if it'd
>     still be desired behavior to ensure the client idle's been updated.
> 
>     Something else might still be buggy here, since I know I've done
>     transfers to a client which take much longer? Can you try testing by
>     reproxying a lot more data with a low timeout? Ten or thirty times more
>     data than your CGI's presently sending.
> 
>     -Dormando
> 
>     Hemant Bist wrote:
>      > Hi Dormando,
>      >
>      > Really appreciate your reply.
>      >
>      > In this case, the 'slow server' is a cgi script, so I guess the
>      > connection from Perlbal to the slow server will not have http
>      > Connection:keep-alive header.
>      > And the cgi script does start sending the data within  first few
>     seconds
>      > and keeps on sending the data.
>      >
>      > If you think I should NOT be receiving the timeout, please do let me
>      > know. I will try to debug it more.
>      >
>      >  On my system, I could reproduce/fix the problem repeatedly by
>     changing
>      > max_idle_time(where you mentioned) and restarting perlbal.(Also
>     if I hit
>      > the url to the slow server directly taking out the perlbal from the
>      > equation, things work fine).
>      >
>      >
>      > [ The reason I updated the max_idle time because I saw  'keep_alive'
>      > parameter  is only updated  in the ClientHTTPBase::event_write.
>      > So my "theory" was that perlbal will kill the connection to
>     backend slow
>      > proxy after 30 sec through Socket::_do_cleanup() function.
>      > event_write will not be called because Perbal will have nothing
>     to write
>      > to the slow proxy after it has sent the get request.
>      >
>      > ]
>      >
>      >
>      >
>      > Thanx,
>      > HB
>      >
> 
>