ngx_http_upstream_round_robin.c

[Maxim Dounin]

Hello!

On Wed, May 16, 2018 at 09:23:44AM +0000, Adam Horvath wrote:

> Hello,
> I am totally new to nginx, so please forgive me if I am wrong.
> 
> I propose the following change:
> https://github.com/nginx/nginx/blob/master/src/http/ngx_http_upstream_round_robin.c#L615
> From:    if (state & NGX_PEER_FAILED)
> To:      if (state & (NGX_PEER_FAILED || NGX_PEER_NEXT))

Suggested change is wrong, as NGX_PEER_NEXT is not expected to 
mark the peer as failed, see documentation here:

http://nginx.org/r/proxy_next_upstream

Rather, it is expected to instruct nginx to try another backend, 
assuming the resource in question is not yet available on the 
particular backend.

[...]

> Regular round robin seems to work fine. But with a configuration like:
> upstream live {
>     server 10.16.48.227:8090;
>     server 10.16.48.228:8090 backup;
> }
> 
> We get a nice failover for HTTP 502. But for HTTP 404 we get a forever-loop, just like the one mentioned in
> Changes with nginx 1.3.0:
>     *) Bugfix: nginx might loop infinitely over backends if the
>        "proxy_next_upstream" directive with the "http_404" parameter was
>        used and there were backup servers specified in an upstream block.
> 
> So we get looping despite the fix. The proposed edit stops the 
> looping for us, but I cannot see the full consequences. And of 
> course it is possible that we can fix it by just some 
> configuration change.
> 
> What do you think?

In the configuration in question and assuming "proxy_next_upstream 
http_404;", nginx is expected to try all backends available, and 
then return 404 to the user.

If in your case it results in an infinite loop, you may want to 
share more details on your configuration.

-- 
Maxim Dounin
http://mdounin.ru/