++1 on this vein of thought. Implementing the health checking similar to the modularized lb methods makes the most sense to me. I can already think of several methods (file, conf, external script, lua script) of obtaining data on how to probe and react.
Just some thoughts worth considering... since you asked :-) *The module should not probe if a probe is already running against that backend (hang or takes too long to respond) *The probes to different backends should be done in parallel rather than serially to avoid pileups due to a slow responder *How will the existing balancer re-enable logic interfere with ERR backends? *Maybe another flag that avoids retry if the monitor marked it down requiring the monitor to bring it back up before any traffic is allowed to go to it? I've followed along with what you described by using watchdog to trigger the probing, but I'm curious where your thoughts are for submitting a request to the backend. Are you planning to simulate one from your module by directly connecting to the backend or is the plan to run the request through the existing proxy infrastructure (the former allows lots of control while the latter permits other directives to come into play that might be handy like disabling based on status code). I haven't seen the code, but your previous email said you were thinking of the former case. P.S. Thanks for taking this on. It's been on my own todo list for a long time. -- Daniel Ruggeri On 1/8/2016 1:09 PM, Jim Jagielski wrote: > Thx! Any other comments/suggestions? > >> On Jan 8, 2016, at 10:53 AM, Eric Covener <[email protected]> wrote: >> >> On Fri, Jan 8, 2016 at 10:18 AM, Jim Jagielski <[email protected]> wrote: >>> I am thinking about the actual health-check impl a bit more, >>> hence the lack of commits. As noted, initially I was thinking >>> about optional functions, defined in mod_proxy_http, mod_proxy_ajp, >>> etc. Then I started thinking that maybe doing it via providers >>> might be better, allowing for more "custom" health checks via >>> the end user. Then I started thinking about doing it rough-and- >>> ready and just adding 'em in mod_proxy_hcheck... >>> >>> Before I spend too much time on this, any prefs one way or >>> another regarding this? >> I haven't looked at the architecture so far -- but I think basics in >> mod_proxy_hcheck >> and at least one "standalone" provider (as an example) would be a good >> middle ground. >> >> Maybe the standalone one would try to deal with the body whereas the >> built-in ones >> would be TCP up, SSL up, status-code, etc.
