You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2006/02/10 06:36:31 UTC
ECONNRESET, low keepalives, and pipelined requests?
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?
Any musings appreciated. =) -- justin
Re: ECONNRESET, low keepalives, and pipelined requests?
Posted by Paul Querna <ch...@force-elite.com>.
>> 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...
>
> That's why we used to send a Keep-Alive: header on responses that
> indicated how many requests were left. Don't get me started...
IMO, since Subversion can control both the server and client, they
should just have mod_dav_svn add this kind of information to its replies....
-Paul
Re: ECONNRESET, low keepalives, and pipelined requests?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
On Feb 9, 2006, at 10:17 PM, Justin Erenkrantz wrote:
> On IRC, Paul pointed out this bug (now fixed):
>
> http://issues.apache.org/bugzilla/show_bug.cgi?id=35292
>
> 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.
You're testing against 2.0.50? Crikey.
> 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...
That's why we used to send a Keep-Alive: header on responses that
indicated how many requests were left. Don't get me started...
....Roy
Re: ECONNRESET, low keepalives, and pipelined requests?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
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):
http://issues.apache.org/bugzilla/show_bug.cgi?id=35292
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
Re: ECONNRESET, low keepalives, and pipelined requests?
Posted by "Roy T. Fielding" <fi...@gbiv.com>.
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