> On Feb 3, 2016, at 7:30 AM, Yann Ylavic <ylavic....@gmail.com> wrote: > > On Wed, Feb 3, 2016 at 1:25 PM, Jim Jagielski <j...@jagunet.com> 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 DISABLED and STOPPED.
