httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <>
Subject Re: ECONNRESET, low keepalives, and pipelined requests?
Date Fri, 10 Feb 2006 06:17:09 GMT
On Thu, Feb 09, 2006 at 10:01:04PM -0800, Roy Fielding wrote:
> Keep in mind that a RST also tells the recipient to throw away any
> data that it has received since the last ACK.  Thus, you would never
> see the server's last response unless you use an external network
> monitor (like another PC running ethereal connected to your client PC
> with a non-switching hub).

Ah - I didn't know RST implies throwing away data.  Hmm.

(I had to scrounge around to find a copy of Stevens since my copies are
back in Orange County...)

> My guess is that, when MaxKeepAliveRequests is reached, the server
> process closes the connection and tells the client.  If lingering
> close hasn't been broken, it will then continue reading some data
> from the client precisely to avoid this lost response problem.
> Serf should be looking for Connection: close on the last response
> it received and close the connection, starting again on a different one.

Right - that's what I'm looking for - but I'm never seeing a full response
or especially one with Connection: close.

> I suggest you check the lingering close code to see if someone has
> disabled it on Linux.  People do that some times because they think
> it is a performance drag to linger on close, neglecting to consider
> that the client will be left clueless if a RST is sent before the
> client acks receipt of the server's response.

On IRC, Paul pointed out this bug (now fixed):

2.0.50 probably has this bug - in that it'll won't do lingering close
correctly - and perhaps that's what I'm running into.

Any cute ideas on how to work around this?  The real problem is that
there's no way for the server to tell me what its configured
MaxKeepAliveRequests setting is.  If I knew that, I could respect it -
instead I have to discover it experimentally...

Thanks!  -- justin

View raw message