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

[dormando]

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
>