upstream member liveness

[B.R.]

Waow.
I am off-topic, but Valentin I shall note you are showing a great deal of
patience.
Without any doubt your interlocutor will be glad and thankful for it, and
will demonstrate it as good as when he (quickly) becomes upset.

Btw, I do not know any Captain Evidence, only Captain Obvious.
---
*B. R.*

On Wed, Apr 13, 2016 at 10:05 AM, Валентин Бартенев <vbart at nginx.com> wrote:

> On Wednesday 13 April 2016 00:47:14 drookie wrote:
> > Is there someone besides Captain Evidence who knows the answer ? This is
> > actually the problem of the modern internet: half of the decent
> questions is
> > flooded out by people, who not only think they know the answer, but are
> > arrogant enough to insist it, and from the point of an outer observer the
> > topic looks "answered".
> >
> [..]
>
> Ok, probably "fastcgi_next_upstream" in my answer misled you, since nginx
> with
> the "upstream" block for sure talks to other nginx instances by HTTP using
> "proxy_pass", then "proxy_next_upstream" would the correct answer in this
> case.
>
> In the configuration below:
>
>    upstream backends {
>        server 192.168.0.1;
>        server 192.168.0.2;
>    }
>
>    proxy_pass http://backends;
>
> nginx doesn't care (and knows nothing) about the virtual hosts presented on
> these servers in the upstream block, and don't try to differentiate
> requests
> in terms of liveness using the host header or any other parameter.
>
> If the "192.168.0.1" will be recognized as dead by the rules that are
> described in the documentation, it will be considered dead for all requests
> for all hosts that use this upstream block.
>
> So the "member liveness" is per upstream group.
>
> What I also wanted to bring to your attention is that by default the 500
> response isn't recognized as a fail attempt, unless you have configured it
> using the proxy_next_upstream, fastcgi_next_upstream, uwsgi_next_upstream,
> or scgi_next_upstream directives (depending on the protocol).
>
>   wbr, Valentin V. Bartenev
>
> _______________________________________________
> nginx mailing list
> nginx at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160413/eafb9d0d/attachment.html>