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