On Tue, Mar 02, 2010 at 03:34:36AM -0500, cep221 wrote:
> > Did you look at ngx_supervisord[1]?
>
> Do you mean use only ngx_supervisord? From what I can tell, it requires a separate daemon running on the machine that does the healthcheck, which then sends a call to nginx via supervisord to turn servers off or on. Is that correct? The goal was to build the checking into nginx so that we don't have to monitor another process, making the system more stable. If nginx is running, then you're guaranteed the health checks are running.
>
> Or did you mean call into ngx_supervisord when a healthcheck fails? I'm happy to integrate other APIs if you have some ideas.

I mean using the same API so that patching a balancer for
ngx_supervisord support would automatically make it support your
healthcheck module. This means that healthcheck would get passed a
callback which should be executed with specified parameters when it
detects a failed backend.

See:
http://github.com/FRiCKLE/ngx_supervisord/blob/master/patches/ngx_http_upstream_round_robin.patch

(grep for ngx_http_upstream_backend_monitor).

I don't expect you to use ngx_supervisord itself (or supervisord), that
would indeed be quite pointless :)

@Piotr: if the health check plugin adapts to ngx_supervisord API, I
guess the API spec could use s/_supervisord//ig, no? A bunch of #defines
should suffice.

Best regards,
Grzegorz Nosek

_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx