Jim Jagielski wrote:
Ideally, it would be nice if we had better insight on the
actual health of the backends than a simple "do they respond
to OPTIONS * and how long does it take", but that's pretty
much all we can do unless go full-on multicasting of info
ala mod_backhand... At least the balanc
On Feb 13, 2008, at 1:49 PM, Mads Toftum wrote:
On Wed, Feb 13, 2008 at 12:22:43PM -0500, Akins, Brian wrote:
Would it be more useful to have active healthchecking to backend
servers?
Ie, periodically hit a url on each origin and mark them up/down
based on
response. Only send traffic to up
On Wed, Feb 13, 2008 at 12:22:43PM -0500, Akins, Brian wrote:
> Would it be more useful to have active healthchecking to backend servers?
> Ie, periodically hit a url on each origin and mark them up/down based on
> response. Only send traffic to up servers. I think mod_backhand does
> something s
On Feb 13, 2008, at 1:22 PM, Nick Kew wrote:
On Wed, 13 Feb 2008 13:18:04 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:
I consider it a Good Sign when the comments are mostly
about the docs and how to better wordsmith them :)
:-)
Not quite sure what problem you're solving, but I accept yo
On Wed, 13 Feb 2008 13:18:04 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:
> I consider it a Good Sign when the comments are mostly
> about the docs and how to better wordsmith them :)
:-)
Not quite sure what problem you're solving, but I accept you
have a reason. But putting the docs first in
On Feb 13, 2008, at 1:13 PM, Nick Kew wrote:
On Wed, 13 Feb 2008 10:27:26 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:
+This helps in various situations where a firewall between
Apache and
+the backend server (irregardless of protocol) tends to silently
irregardless??? Regardless
On Feb 13, 2008, at 1:09 PM, Plüm, Rüdiger, VF-Group wrote:
Right. Furthermore I guess we could create a generic module that
needs a
URL configured for a HEAD request that only replies 200 if the
backend can
still handle more requests. If it does not respond or with a
different code
this
On Feb 13, 2008, at 1:04 PM, Plüm, Rüdiger, VF-Group wrote:
Sorry for my I-want-it-all-at-once approach :-). But this leaves
the problems (most notably PR 37770) open for SSL backend connection
(which would be a pity). So IMHO the socket approach would be only a
first step.
No, I want it a
On Wed, 13 Feb 2008 10:27:26 -0500
Jim Jagielski <[EMAIL PROTECTED]> wrote:
> +This helps in various situations where a firewall between
> Apache and
> +the backend server (irregardless of protocol) tends to silently
irregardless??? Regardless?
> +drop connections. To prevent mod_pr
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Mittwoch, 13. Februar 2008 19:00
> An: dev@httpd.apache.org
> Betreff: Re: ping for http in mod_proxy
>
>
> On Feb 13, 2008, at 12:41 PM, Plüm, Rüdiger, VF-Group wrote:
> >
> > Agreed, but I doubt that it is possible with a
On Feb 13, 2008, at 12:59 PM, Plüm, Rüdiger, VF-Group wrote:
We will never be able to completely avoid race conditions...
whether keepalives are in place or not.
But at least the one that comes from the keepalive timer expiring on
the backend at the same time I sent the request to it. If the
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 13. Februar 2008 18:55
> An: dev@httpd.apache.org
> Betreff: Re: ping for http in mod_proxy
>
>
> On Feb 13, 2008, at 12:23 PM, Plüm, Rüdiger, VF-Group wrote:
>
> >
> >
> >> -Ursprüng
On Feb 13, 2008, at 12:41 PM, Plüm, Rüdiger, VF-Group wrote:
Agreed, but I doubt that it is possible with a reasonable amout of
health
check frequency to find out before the first real request falls
through,
provided that your health checks are designed to only fail if the
backend
is down
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Mittwoch, 13. Februar 2008 18:52
> An: dev@httpd.apache.org
> Betreff: Re: ping for http in mod_proxy
>
>
> On Feb 13, 2008, at 12:27 PM, Plüm, Rüdiger, VF-Group wrote:
>
> >
> >
> >> -Ursprüngliche Nachricht-
> >>
On Feb 13, 2008, at 12:23 PM, Plüm, Rüdiger, VF-Group wrote:
-Ursprüngliche Nachricht-
Von: Jim Jagielski
Gesendet: Mittwoch, 13. Februar 2008 17:07
An: dev@httpd.apache.org
Betreff: ping for http in mod_proxy
I've started looking at adding "ping" support for
mod_proxy_http to compl
On Feb 13, 2008, at 12:27 PM, Plüm, Rüdiger, VF-Group wrote:
-Ursprüngliche Nachricht-
Von: Akins, Brian
Gesendet: Mittwoch, 13. Februar 2008 18:23
An: dev@httpd.apache.org
Betreff: Re: ping for http in mod_proxy
On 2/13/08 11:07 AM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote:
I've
On Feb 13, 2008, at 12:22 PM, Akins, Brian wrote:
On 2/13/08 11:07 AM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote:
I've started looking at adding "ping" support for
mod_proxy_http to complement whats in mod_proxy_ajp...
The idea is to send a simple OPTIONS * to the backend
and hope for a reply
On 2/13/08 12:41 PM, "Plüm, Rüdiger, VF-Group" <[EMAIL PROTECTED]>
wrote:
> If your health checks are smarter and notice that the backend will
> fail soon (e.g. because it reached 98% or 99% percent of its capacity) then
> this is a different story and can be very useful.
Correct. Perhaps a weigh
> -Ursprüngliche Nachricht-
> Von: Akins, Brian
> Gesendet: Mittwoch, 13. Februar 2008 18:34
> An: dev@httpd.apache.org
> Betreff: Re: ping for http in mod_proxy
>
> On 2/13/08 12:27 PM, "Plüm, Rüdiger, VF-Group"
> <[EMAIL PROTECTED]>
> wrote:
>
> > This does not help with race condi
Sorry again for the lack of attachment. :(
There definitely is confusion here and it's definitely my
fault. First, the lack of attachment. Second, I have
made this both a fix *and* a feature both of which only
apply to the 2.0 line.
I'm including the patch again and can modify it to include
jus
On 2/13/08 12:27 PM, "Plüm, Rüdiger, VF-Group" <[EMAIL PROTECTED]>
wrote:
> This does not help with race conditions on HTTP keepalive connections.
> Nevertheless active healthchecking could be useful. But on a busy site
> I guess a real request will notice before the healthcheck that one backend
>
Ack, I'm so sorry for not including the attachment. Further
complicating the issue, for some reason, emails from this
list are getting eaten or delayed by my company's server and
so I didn't even see the responses to my original mail until
now, a week later. :(
(I've always felt that email client
> -Ursprüngliche Nachricht-
> Von: Akins, Brian
> Gesendet: Mittwoch, 13. Februar 2008 18:23
> An: dev@httpd.apache.org
> Betreff: Re: ping for http in mod_proxy
>
> On 2/13/08 11:07 AM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote:
>
> > I've started looking at adding "ping" support for
> -Ursprüngliche Nachricht-
> Von: Jim Jagielski
> Gesendet: Mittwoch, 13. Februar 2008 17:07
> An: dev@httpd.apache.org
> Betreff: ping for http in mod_proxy
>
> I've started looking at adding "ping" support for
> mod_proxy_http to complement whats in mod_proxy_ajp...
> The idea is t
On 2/13/08 11:07 AM, "Jim Jagielski" <[EMAIL PROTECTED]> wrote:
> I've started looking at adding "ping" support for
> mod_proxy_http to complement whats in mod_proxy_ajp...
> The idea is to send a simple OPTIONS * to the backend
> and hope for a reply.
Would it be more useful to have active heal
I've started looking at adding "ping" support for
mod_proxy_http to complement whats in mod_proxy_ajp...
The idea is to send a simple OPTIONS * to the backend
and hope for a reply.
The rub is that I've been working on 2 separate
implementations: one talks direct to the socket and the
other basica
On Feb 13, 2008, at 10:45 AM, Erik Abele wrote:
On 13.02.2008, at 16:27, Jim Jagielski wrote:
I added something similar to mod_jk quite awhile ago, and
I'm trying to get mod_jk and mod_proxy closer to parity,
esp for those using AJP. So with that in mind, comments
on the below??
Index: docs/
On 13.02.2008, at 16:27, Jim Jagielski wrote:
I added something similar to mod_jk quite awhile ago, and
I'm trying to get mod_jk and mod_proxy closer to parity,
esp for those using AJP. So with that in mind, comments
on the below??
Index: docs/manual/mod/mod_proxy.xml
==
I added something similar to mod_jk quite awhile ago, and
I'm trying to get mod_jk and mod_proxy closer to parity,
esp for those using AJP. So with that in mind, comments
on the below??
Index: docs/manual/mod/mod_proxy.xml
===
--- do
While I was testing revocation checking for client certs in an SNI
configuration (Dirk, many thanks for make_sni.sh, btw!), I came across a
flaw in the current implementation when CRL information - i.e.
SSLCARevocationFile/SSLCARevocationPath - is set on a per-vhost basis
(don't know how much sense
30 matches
Mail list logo