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 BB4611069D for ; Thu, 5 Dec 2013 16:07:37 +0000 (UTC) Received: (qmail 88724 invoked by uid 500); 5 Dec 2013 16:07:35 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 88509 invoked by uid 500); 5 Dec 2013 16:07:35 -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 88501 invoked by uid 99); 5 Dec 2013 16:07:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Dec 2013 16:07:34 +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.182 as permitted sender) Received: from [209.85.223.182] (HELO mail-ie0-f182.google.com) (209.85.223.182) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 05 Dec 2013 16:07:28 +0000 Received: by mail-ie0-f182.google.com with SMTP id as1so29910319iec.27 for ; Thu, 05 Dec 2013 08:07:07 -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=1/rwuNw1MkjPKoosO7QuI4glTHEe8M2PGDl6jsTwWEU=; b=Fl4FxhawJC5cy9sFujDNDi55hWNZrcyrKnlQSvX0BVEvSygc+ZvHlGKuNz2OnDMtn+ DDIxWfvqli2KQus80+zqoo53iL/u85srypTvagqwtk6SSghfLjj4iw5PlqdT9oamMvc/ UWI4HzmBsYuJX8RHd5HwrgCqSnFAYzUvv0/85gdMScHppmk0moBN99svncKZDcOq1Qjp 6BYOAGQsGB+YZHzgCzo8FJKiM8nR3dMZZ5cltP6IWPtmGDN9FtK2fgQ0c+fQIycmTzHg XUuvJPdCfsqJw4+H9d9+4lrG5LN54q80x13FJ1rmSnhTGFBC0UF2S9+iDOPdFJfH0GqT O80Q== MIME-Version: 1.0 X-Received: by 10.50.66.101 with SMTP id e5mr6918265igt.26.1386259627285; Thu, 05 Dec 2013 08:07:07 -0800 (PST) Received: by 10.43.133.70 with HTTP; Thu, 5 Dec 2013 08:07:07 -0800 (PST) In-Reply-To: <6E8DB969-9CCD-4AD4-9265-42B510C7AC5C@jaguNET.com> References: <20131001122239.GA28849@redhat.com> <52A076E5.2080906@redhat.com> <6E8DB969-9CCD-4AD4-9265-42B510C7AC5C@jaguNET.com> Date: Thu, 5 Dec 2013 17:07:07 +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=001a1135ec0ca6a42b04eccbb8d7 X-Virus-Checked: Checked by ClamAV on apache.org --001a1135ec0ca6a42b04eccbb8d7 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Dec 5, 2013 at 4:05 PM, Jim Jagielski wrote: > There hardly seemed any consensus on the patch... It also > seems that it adds more cycles to Apache on the front to > reduce a race condition that can't really be removed. > I don't think more cycles are added by this patch. What is done is that ap_proxy_http_request() is split in two functions, the prefetch part is now in ap_proxy_http_prefetch(), and ap_proxy_http_prefetch()+ap_proxy_http_request() has no more cycles than the previous ap_proxy_http_request(). Unless you consider dereferencing pointer arguments a cycles-overhead compared to using local variables... I agree the race condition can't really be removed, mod_proxy can (must?) strive for limiting it. With this patch and the reslist's TTL below the backend's KeepAliveTimeout, the race should not occur unless the backend closed before the timeout (which may indeed be the case when, say, mpm_event is busy). > IMO, a reverse proxy should get out of the way as > quickly as possible. > I'm not sure to understand this but, IMHO, a reverse proxy should not "reserve" a backend connection (possibly) far before using it, and presume it will still be alive when it's time to use it. > > Plus, if we do this here, shouldn't we do it for > all proxy protocol submodules (fcgi, etc...)? > Agreed. > > Plus, as mentioned, this single patch includes 2 "fixes" > which can be/should be independent. > This was just to show that "early prefetch" and "flushall" can work together, but they are indeed 2 different things. I can split them into different patches, should there be an interest in one or/and the other. Regards, Yann. --001a1135ec0ca6a42b04eccbb8d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 5, 2013 at 4:05 PM, Jim Jagielski <jim@jagunet.com> wr= ote:
There hardly seemed any consensus on the patch... It also
seems that it adds more cycles to Apache on the front to
reduce a race condition that can't really be removed.
<= div>
I don't think more cycles are added by this patch.
What i= s done is that ap_proxy_http_request() is split in two functions, the prefe= tch part is now in ap_proxy_http_prefetch(), and ap_proxy_http_prefetch()+a= p_proxy_http_request() has no more cycles than the previous ap_proxy_http_r= equest().
Unless you consider dereferencing pointer arguments a cycles-overhead compa= red to using local variables...

I agree the race condition = can't really be removed, mod_proxy can (must?) strive for limiting it.<= br>
With this patch and the reslist's TTL below the backend's = KeepAliveTimeout, the race should not occur unless the backend closed befor= e the timeout (which may indeed be the case when, say, mpm_event is busy).<= br>

=A0
IMO, a reverse proxy should get out of the way as
quickly as possible.

I'm not= sure to understand this but, IMHO, a reverse proxy should not "reserv= e" a backend connection
=A0
(possibly) far before using it, and presume it will st= ill be alive when it's time to use it.

=A0

Plus, if we do this here, shouldn't we do it for
all proxy protocol submodules (fcgi, etc...)?

Agreed.


=A0

Plus, as mentioned, this single patch includes 2 "fixes"
which can be/should be independent.

This was j= ust to show that "early prefetch" and "flushall" can wo= rk together, but they are indeed 2 different things.
I can split them into different patches, should there= be an interest in one or/and = the other.

<= span class=3D"">Regards,
Yann.

--001a1135ec0ca6a42b04eccbb8d7--