<div dir="ltr"><div>>> diff -ur /old/src/http/ngx_http_upstream.c /new/src/http/ngx_http_upstream.c<br></div><div><div>>> --- /old/src/http/ngx_http_upstream.c    2013-04-21 18:25:09.619437856 +0000</div><div>>> +++ /new/src/http/ngx_http_upstream.c    2013-04-23 21:29:06.106568703 +0000</div>
<div>>> @@ -2904,6 +2904,11 @@</div><div>>>      if (status) {</div><div>>>          u->state->status = status;</div><div>>> </div><div>>> +        if (u->conf->next_upstream_tries != NGX_CONF_UNSET_UINT && ++r->us_tries >= u->conf->next_upstream_tries) {</div>
<div>>> +                ngx_http_upstream_finalize_request(r, u, status);</div><div>>> +                return;</div><div>>> +        }</div><div>>> +</div><div>>>          if (u->peer.tries == 0 || !(u->conf->next_upstream & ft_type)) {</div>
<div>>> </div><div>>>  #if (NGX_HTTP_CACHE)</div><div>></div><div>>Introducing r->us_tries for this looks wrong, there is no need for </div><div>>such counter at request level.  Instead, probably u->peer.tries </div>
<div>>should be set accordingly.</div><div>></div><div>>The test against NGX_CONF_UNSET_UINT looks wrong, too, and </div><div>>suggests that configuration inheritance isn't handled properly.</div><div><br>
</div><div>[Gist: <a href="https://gist.github.com/shai-d/5446961">https://gist.github.com/shai-d/5446961</a>  ]</div><div><br></div><div>Maxim, thank you for your review! :)</div><div><br></div><div>I agree about comparing to NGX_CONF_UNSET_UINT. It should be set to 0 (endless tries) by default. </div>
<div><br></div><div>I avoided u->peer.tries because we wanted N retries per request and not N retries per upstream.</div><div>As I understand it, all requests share the same instance of peers.</div><div>If this is the case, In a high concurrency system with some percentage of errors, peers will statistically always have tries > N and many requests will be lost.</div>
<div>Am I wrong?</div></div></div>