| Hemant Bist 2007-09-18, 1:11 am |
| 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
On 9/17/07, dormando <dormando@rydia.net> wrote:I
> If this is the code you edited:
>
> # FIXME: let this be configurable?
> sub max_idle_time { 30; }
>
> ... then likely, yes.
>
> The latest SVN tree has the configurable 'persist_client_timeout'
> merged. That only appears to affect the keep alives though? If your
> server's taking a long time to initially start feeding data back to the
> client, and you've already established a keepalive connection, this will
> matter.
>
> -Dormando
>
> Hemant Bist wrote:
>
>
|