Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of minfrin@sharp.fm designates
 72.32.122.20 as permitted sender)
Message-Id: <119AF357-7D77-4430-AAC0-1AD66AA4787D@sharp.fm>
From: Graham Leggett <minfrin@sharp.fm>
To: dev@httpd.apache.org
In-Reply-To: <1320773172.209.1290172793330.JavaMail.root@iris>
Content-Type: text/plain; charset=UTF-8; format=flowed; delsp=yes
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Subject: Re: svn commit: r1035605 -
 /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
Date: Fri, 19 Nov 2010 16:49:27 +0200
References: <1320773172.209.1290172793330.JavaMail.root@iris>

On 19 Nov 2010, at 3:19 PM, Igor Gali=C4=87 wrote:

> I believe to have, for the first time in months, understood what it
> is with mod_proxy, and why it's so heavily discussed:
>
> There are a number separate and related issues, because mod_proxy:
>
> * handles connections to the front end
>  (To large numbers of differently behaving clients)
> * handles (highly configurable) connections to the back-end
> * can speak very different protocols to the back-ends
>  (In terms of timeouts, keep-alives, etc..)
> * can be a transparent proxy as well as a reverse proxy
>
> * The code might, or might not be heavily interwoven.
>
> is that remotely right?

It can be safe to say "mod_proxy relies heavily on pool lifetimes =20
being correct".

In most cases in the server, the only pool you care about is the =20
request pool. When the request is cleaned up, so is your data, and =20
you're done. In these cases, you simply don't care about pool =20
lifetimes, and because you're only using a pool you've already been =20
given, the lifetime simply isn't your problem.

In the case of mod_proxy however, a backend connection may start life =20=

either before or after the frontend connection, and may terminate =20
before or after the frontend connection terminates. The backend has a =20=

completely separate lifetime to the frontend.

What this means is, if there are pool lifetime issues hidden in the =20
server, proxy is likely to show them up first.

Regards,
Graham
--