httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Querna <p...@querna.org>
Subject Re: trunk "ping" for http proxy
Date Tue, 17 Aug 2010 03:42:13 GMT
On Mon, Aug 16, 2010 at 2:28 PM, Andrew Oliver <acoliver@gmail.com> wrote:
> Note that it is an option, not a default setting.  The problem with
> the heartbeat bit which Red Hat/JBoss use is the unstandardized
> proprietary protocol required (http://jboss.org/mod_cluster) with
> separate logic to manage it.

No, in 2.3/trunk, there is a bundled module to provide this in httpd:
https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/cluster/mod_heartmonitor.c
https://svn.apache.org/repos/asf/httpd/httpd/trunk/modules/proxy/balancers/mod_lbmethod_heartbeat.c

> The problem with the status url is that it doesn't accomplish the same
> thing nor is it that very manageable with multiple contexts (i.e
> http://server1:8080/foo http://server1:8081/bar ...).  You'd have to
> make a separate request each time.
>
> Purpose:
>
> C = Browser
> P = middle apache server
> W = destination web server (probably tomcat)
>
> C------>P------->W
>
> C asks for http://myserver/someDatabaseBackedThing
> P matches and forwards this request to W with the expect continue and
> specified 5 sec expect-continue timeout.  A separate overall proxy
> timeout of 1 minute is set.
> W returns a continue but then begins to process the request
> (CGI/JavaServlet/PHP whatever to the database)
> W spends less than a minute and the request is successful
>
> C asks for http://myserver/someDatabaseBackedThing
> P matches and forwards this request to W with the expect continue and
> specified 5 sec expect-continue timeout.  A separate overall proxy
> timeout of 1 minute is set.
> W does not return a continue or any kind of response for 5 seconds
> P marks that worker dead meat
>
> C asks for http://myserver/someDatabaseBackedThing
> P matches and forwards this request to W with the expect continue and
> specified 5 sec expect-continue timeout.  A separate overall proxy
> timeout of 1 minute is set.
> W returns a continue but then begins to process the request
> (CGI/JavaServlet/PHP whatever to the database)
> W spends more than a minute and the proxy request times out
>
> The case of a dead connector things back out rather nicely and its
> clearly distinguishable from a bad script.
>
> -Andy
>
> On Mon, Aug 16, 2010 at 2:52 PM, Jim Jagielski <jim@jagunet.com> wrote:
>>
>> On Aug 16, 2010, at 1:42 PM, Paul Querna wrote:
>>
>>> On Mon, Aug 16, 2010 at 8:30 AM, Jim Jagielski <jim@jagunet.com> wrote:
>>>>
>>>> On Aug 16, 2010, at 10:56 AM, Plüm, Rüdiger, VF-Group wrote:
>>>>>
>>>>> This basicly sums up the downsides of this approach I see as well.
>>>>>
>>>>> IMHO to avoid a spec violation we can only add the Expect header to
>>>>> requests with request bodies. OTOH these requests hurt most when they
>>>>> fail as we cannot sent the request body for a second time, because
>>>>> we do not have it any longer available in most situations and requests
>>>>> with request bodies are usually not idempotent.
>>>>>
>>>>> On the second issue we only need to take care that we do not add something
>>>>> already there and remove something that client expects to see.
>>>>>
>>>>> One last thing I see is that this only works if the backend is HTTP/1.1:
>>>>>
>>>>> 8.2.3
>>>>>
>>>>> - If the proxy knows that the version of the next-hop server is HTTP/1.0
or lower
>>>>>  , it MUST NOT forward the request and it MUST respond with a 417 (Expectation
Failed)
>>>>>  status.
>>>>
>>>> Yes, the code itself is aware of the limitations of 100-Continue,
>>>> including version and req body considerations... It's not ideal,
>>>> but it's better than the OPTIONS method which I played around
>>>> with earlier...
>>>>
>>>> Still I think it's useful to add it in, have it disabled by
>>>> default, and see how far we can take it...
>>>
>>> I think the only options really are a status URL, with a regex match,
>>> so you can test if the backend has an expected content, and having the
>>> backends advertise/notify the proxy that they are alive.
>>>
>>
>> Well, OPTIONS is the defacto "HTTP ping" but it's also considered
>> a "request" (afaik), and so things like keepalives, etc matter.
>> That was the issue I ran into is that checking with OPTIONS
>> doesn't totally remove the problem, esp for non-keepalive
>> connections or one-shots, and then you need to worry if that
>> last OPTIONS forced a connection that was in keepalive mode
>> to close and all that junk....
>>
>> What I just committed is not the ideal solution, but like you
>> said, the real way to do this is non-trivial with the current
>> architecture...
>>
>>
>

Mime
View raw message