new directive: "proxy_next_tries N"

[Shai Duvdevani]

Hi Ruslan,
I agree, I think it should be in the request too.
There's only 1 "request retry" per request, there's no point in putting it
anywhere else.


On Wed, Apr 24, 2013 at 5:57 PM, Ruslan Ermilov <ru at nginx.com> wrote:

> On Wed, Apr 24, 2013 at 04:32:20PM +0300, Shai Duvdevani wrote:
> > >> diff -ur /old/src/http/ngx_http_upstream.c
> > /new/src/http/ngx_http_upstream.c
> > >> --- /old/src/http/ngx_http_upstream.c    2013-04-21 18:25:09.619437856
> > +0000
> > >> +++ /new/src/http/ngx_http_upstream.c    2013-04-23 21:29:06.106568703
> > +0000
> > >> @@ -2904,6 +2904,11 @@
> > >>      if (status) {
> > >>          u->state->status = status;
> > >>
> > >> +        if (u->conf->next_upstream_tries != NGX_CONF_UNSET_UINT &&
> > ++r->us_tries >= u->conf->next_upstream_tries) {
> > >> +                ngx_http_upstream_finalize_request(r, u, status);
> > >> +                return;
> > >> +        }
> > >> +
> > >>          if (u->peer.tries == 0 || !(u->conf->next_upstream &
> ft_type)) {
> > >>
> > >>  #if (NGX_HTTP_CACHE)
> > >
> > >Introducing r->us_tries for this looks wrong, there is no need for
> > >such counter at request level.  Instead, probably u->peer.tries
> > >should be set accordingly.
> > >
> > >The test against NGX_CONF_UNSET_UINT looks wrong, too, and
> > >suggests that configuration inheritance isn't handled properly.
> >
> > [Gist: https://gist.github.com/shai-d/5446961  ]
> >
> > Maxim, thank you for your review! :)
> >
> > I agree about comparing to NGX_CONF_UNSET_UINT. It should be set to 0
> > (endless tries) by default.
> >
> > I avoided u->peer.tries because we wanted N retries per request and not N
> > retries per upstream.
>
> You store the limit per upstream{}, but want it to affect tries
> per request?  That's kinda strange.
>
> > As I understand it, all requests share the same instance of peers.
> > 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.
> > Am I wrong?
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130424/0039fee2/attachment.html>