httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: Worker states for balancer members
Date Wed, 03 Feb 2016 14:09:16 GMT

> On Feb 3, 2016, at 7:30 AM, Yann Ylavic <> wrote:
> On Wed, Feb 3, 2016 at 1:25 PM, Jim Jagielski <> wrote:
>> I WAS thinking about basically "making" HC_FAIL STOPPED because
>> that mode can only be set/cleared during configuration (the
>> balancer-manager doesn't provide for changing that bit) and so
>> for the life of me I can't figure out how or why anyone would be
>> using that status since it never changes...
>> Maybe we can just say that STOPPED is there for potential
>> 3rd party uses and be done w/ it :)
> That's what I started to respond before yours :)
> Pasting below...
> Some third-party (proxy_)modules may use DISABLED/STOPPED for their
> own purpose, but I wouldn't mind if the health check DISABLEs or STOPs
> a worker under them, these are httpd #defined yet...
> So I would have been for health check to reuse STOPPED for its own
> purpose (since DISABLED is exposed via the balancer-manager, we likely
> can't change its behaviour).
> But DISABLED/STOPPED are also configurable with BalancerMember's
> status=+D/S, and ~documented~ :)
>  D: Worker is disabled and will not accept any requests.
>  S: Worker is administratively stopped.
> Here both really mean "not started", so status=+S workers shouldn't be
> started later by the health check on its own, which prevents STOPPED
> reuse too.
> Thus, as you suggest, we need a different a new name for health check
> (HC_FAIL), so why join the two others (with a nice trick btw)?
> We probably need to keep their current/synonym meaning in httpd (at
> least in 2.4.x), and maybe we can let third party modules play with
> them distinctly after all :)

Currently, this is the impl:

When a backend can't be contacted, it is put in the ERROR state. If
the worker is set with IGNORE_ERRORS it is immediately allowed to be
retried, otherwise we wait the selected amount and retry after the
delay. If the worker is also in STOPPED, then the retry will never
happen. In other words, a STOPPED worker will never be used and will
never automatically be re-enabled. If the worker is DISABLED, then
retry will still happen and the worker could be re-enabled.

Right now, the health check module only worries about checking
workers which are USABLE, which is a worker which is !DISABLED
and !STOPPED and !IN_ERROR (basically).

I've started adjusting the docs to better clarify the diff between

View raw message