Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <45E33DB6.1040707@hanik.com>
Date: Mon, 26 Feb 2007 13:06:14 -0700
From: Filip Hanik - Dev Lists <devlists@hanik.com>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Small patch to ab apr_socket_recv error handling
Content-Type: multipart/mixed;
 boundary="------------080102010201060607040507"

This is a multi-part message in MIME format.
--------------080102010201060607040507
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I've created a small patch that lets ab continue even if it encounters 
an error on apr_socket_recv

quite commonly, when servers are overloaded they disconnect the socket, 
ab receives a 104 (connection reset by peer) and the ab test exits.

This patch logs the error, both counters correctly, cleans up the 
connection and continues.

thoughts?

Filip

--------------080102010201060607040507
Content-Type: text/plain;
 name="fix-ab-recv-error.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="fix-ab-recv-error.patch"

Index: ab.c
===================================================================
--- ab.c	(revision 511976)
+++ ab.c	(working copy)
@@ -1332,7 +1332,10 @@
             err_except++; /* XXX: is this the right error counter? */
             /* XXX: Should errors here be fatal, or should we allow a
              * certain number of them before completely failing? -aaron */
-            apr_err("apr_socket_recv", status);
+            //apr_err("apr_socket_recv", status);
+            bad++;
+            close_connection(c);
+            return;
         }
     }
 

--------------080102010201060607040507--