Hold requests long enough for me to restart upstream?
Rt Ibmer
rtibmx at yahoo.com
Sat Mar 21 03:07:15 MSK 2009
Correct - just one upstream right now. So what I am looking for would essentially be a "pause". To tell it "hey if nothing's listening and there's no other upstream just queue the requests and wait x seconds, then retry".
So it sounds like there is nothing to do this right now. Perhaps it is a feature to be considered. Thanks.
--- On Fri, 3/20/09, Cliff Wells <cliff at develix.com> wrote:
> From: Cliff Wells <cliff at develix.com>
> Subject: Re: Hold requests long enough for me to restart upstream?
> To: nginx at sysoev.ru
> Date: Friday, March 20, 2009, 10:32 PM
> On Fri, 2009-03-20 at 13:48 -0700,
> mike wrote:
> > On Fri, Mar 20, 2009 at 1:36 PM, Cliff Wells <cliff at develix.com>
> wrote:
> > > It does, but the OP only has a single upstream.
> >
> > Ah.
> >
> > I wonder, but what if the OP put the same upstream
> down multiple times
> > in an upstream {} block with appropriate retry/timeout
> settings, like
> > so...
> >
> > max_fails=1 fail_timeout=20s;
> >
> > Essentially it would be a loop but it would allow to
> retry the same
> > upstream (assuming nginx does not have an internal
> table that rejects
> > or malfunctions if you define the same upstream more
> than once)
>
> This won't work. The problem is that his backend
> isn't unresponsive,
> it's *down*. That is, the backend socket
> isn't even open. Timeouts
> are for sockets that are "open but unresponsive", not
> sockets that are
> "closed".
>
> In this case Nginx would try each backend and *instantly*
> go to the next
> one until it ran out of backends and then it would throw a
> 50x error.
>
> Cliff
>
>
>
>
More information about the nginx
mailing list