httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roy T. Fielding" <field...@gbiv.com>
Subject Re: ECONNRESET, low keepalives, and pipelined requests?
Date Fri, 10 Feb 2006 06:01:04 GMT
On Feb 9, 2006, at 9:36 PM, Justin Erenkrantz wrote:

> Has anyone ever seen a situation where httpd (or the OS) will RST a
> connection because there's too much unread data or such?
>
> I'm doing some pipelined requests with serf against a 2.0.50 httpd  
> on RH7.1
> server (2.4.2 kernel?).  I'm getting ECONNRESET on the client after  
> I try
> to read or write a large number of requests.  httpd's side is  
> sending the
> RSTs - but there's nothing in the httpd logs.
>
> Can an RST happen without a process dying?  Isn't that the most common
> reason for the RST flag?  (We've checked and no httpd are dying,  
> AFAICT.)
>
> Bumping the MaxKeepAliveRequests from 10 to 100 apparently solves  
> this; but
> that's just odd - yet it implies that httpd is in some control over  
> this
> behavior.
>
> Yet, if it were httpd, why isn't it responding to all of the previous
> requests before it hit the MaxKeepAliveRequests?  (There is no  
> response
> with 'Connection: Close' being sent - it just drops off in the  
> middle of
> writing the response body as far as we can see.)  So, why would it
> terminate the connection *before* responding to all of the outstanding
> responses that are under the MaxKeepAliveRequests limit?  Is httpd  
> writing
> the response and Linux just dropping it?

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).

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.

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.

....Roy

Mime
View raw message