httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Graham Leggett <minf...@sharp.fm>
Subject Re: svn commit: r1035605 - /httpd/httpd/trunk/modules/proxy/mod_proxy_http.c
Date Fri, 19 Nov 2010 14:49:27 GMT
On 19 Nov 2010, at 3:19 PM, Igor Galić 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  
being correct".

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

In the case of mod_proxy however, a backend connection may start life  
either before or after the frontend connection, and may terminate  
before or after the frontend connection terminates. The backend has a  
completely separate lifetime to the frontend.

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

Regards,
Graham
--


Mime
View raw message