Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 142B9109AD for ; Fri, 6 Dec 2013 09:59:07 +0000 (UTC) Received: (qmail 97590 invoked by uid 500); 6 Dec 2013 09:57:54 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 97388 invoked by uid 500); 6 Dec 2013 09:57:30 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 97185 invoked by uid 99); 6 Dec 2013 09:56:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Dec 2013 09:56:45 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of ylavic.dev@gmail.com designates 209.85.223.170 as permitted sender) Received: from [209.85.223.170] (HELO mail-ie0-f170.google.com) (209.85.223.170) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Dec 2013 09:56:38 +0000 Received: by mail-ie0-f170.google.com with SMTP id qd12so804447ieb.1 for ; Fri, 06 Dec 2013 01:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=g43JMxRzSw8doG10GKaPUqcfRRykvJxadVj3alj9flU=; b=dqdOZaV+NW1wWhFMhYPYmvvPy+qx+zRdxWCE22INhOdK57xZvV4oSLIPZthabeR6xI 8RwDH4ZbYhoXTrHrgcipeiA/Wklvlo9b/D41CvO9BYVJzweOobED9iP9bE1TdQU8S1tp MFaEM6maIi62KM10jM2Wx252GS6Of/l/Mz+SfSgpA7pDyu4PG8ar5J1OaJRWqSPmpa0f FmLSOkX0uDaWMBdTQZYOMqNTyRcWm5v6lB8OoznlJKWN9Swy/HQTlUnRs1Y3vmMP/2Qf /oI/gODWb3Ah01yhFktLP552/hBsnWp1zY2wAz17qufkBKf95dkcKIvqGepG/uSsK/Xv sa6g== MIME-Version: 1.0 X-Received: by 10.50.66.101 with SMTP id e5mr1756403igt.26.1386323777531; Fri, 06 Dec 2013 01:56:17 -0800 (PST) Received: by 10.43.133.70 with HTTP; Fri, 6 Dec 2013 01:56:17 -0800 (PST) In-Reply-To: References: <20131001122239.GA28849@redhat.com> <52A076E5.2080906@redhat.com> <6E8DB969-9CCD-4AD4-9265-42B510C7AC5C@jaguNET.com> Date: Fri, 6 Dec 2013 10:56:17 +0100 Message-ID: Subject: Re: mod_proxy, oooled backend connections and the keep-alive race condition From: Yann Ylavic To: httpd Content-Type: multipart/alternative; boundary=001a1135ec0c4db3df04ecdaa80a X-Virus-Checked: Checked by ClamAV on apache.org --001a1135ec0c4db3df04ecdaa80a Content-Type: text/plain; charset=ISO-8859-1 I don't want to overdo this thread (apologies if it is already), last comment yet... On Thu, Dec 5, 2013 at 10:03 PM, Yann Ylavic wrote: > Is sending a partial request first what you'd like to (be) implement(ed), > and only if that succeeds send the remaining data? > The issue would still be there for the remaining data since nothing guarantees the partial (initial) sending has reached the backend, which might still have closed the connection in the meantime ("error reading status line from remote server" is the proof, the failure occurs on the recv(), not the send()). Maybe one (other than me) facing the race condition can give my patch a chance (no more "error reading status line..." here with TTL < KA-timeout, pretetch, and slow clients). No noticeable slow-down either, although statements like this are worthless without measure... I plan to do that soon (and keep you informed, for those who still care :) Regards, Yann. --001a1135ec0c4db3df04ecdaa80a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I don't want to overdo this thread (apologies if it= is already), last comment yet...

<= div class=3D"gmail_quote"> On Thu, Dec 5, 2013 at 10:03 PM, Yann Ylavic <ylavic.dev@gmail.com= > wrote:
Is sending a partial= request first what you'd like to (be) implement(ed), and only if that = succeeds send the remaining data?

The issue would still be there for = the remaining data since nothing guarantees the partial (initial) sending h= as reached the backend, which might still have closed the connection in the= meantime ("error reading status line from remote server" is the = proof, the failure occurs on the recv(), not the send()).

Maybe one (other than me) facing the race condi= tion can give my patch a chance (no more "error reading status line...= " here with TTL < KA-timeout, pretetch, and slow clients).

No noticeable slow-down either, although statements= like this are worthless without measure...
I plan to do that soon (and keep you informed, for those who still care :)<= br>

Regards,
Yann.
--001a1135ec0c4db3df04ecdaa80a--