Nginx response with persistence session and backend server failure

Hello all,

I was reading Nginx documentation
http://nginx.org/en/docs/http/ngx_http_upstream_module.html?&_ga=1.189051176.2090890265.1437394769#sticky_cookie
on
persistence session using cookie and below is from documentation

A request that comes from a client not yet bound to a particular server
is
passed to the server selected by the configured balancing method.
Further
requests with this cookie will be passed to the designated server. If
the
designated server cannot process a request
, the new server is selected
as
if the client has not been bound yet
.

The last line says that

If the designated server cannot process a request.

What does it mean to say “the server cannot process a request.”

Question 1:
Does it mean the server was down ?
or does it mean server responded with some error code ?
or does it mean that it did not responded in a certain time interval ?
or does it mean that max number of connection limit is reached on that
server ?

Question 2:
Let say there were 3 backend-server and we are using session persistence
using cookie.
Now assume that 2 of the backed server goes down so niginx will route
all
request to 3rd server
Now 2 other server came back online, will niginx use the other 2 server
to
route the request even if request have the persistence cookie for 3rd
server.

Thanks

On Mon, Jul 27, 2015 at 9:10 AM, Bhuvan G. [email protected]
wrote:

the designated server cannot process a request*, *the new server is
or does it mean server responded with some error code ?
or does it mean that it did not responded in a certain time interval ?
or does it mean that max number of connection limit is reached on that
server ?

​It seems pretty clear to me that it describes whatever reason a server
could have of not being able to handle a request.
Your points #1 and #3 cannot be differenciated from a client point of
view.
Your point #4 makes the connection being refused (or times out? then it
joins the 2 first points).​
In thoses cases, the load balancer will try to find some machine
accepting
the request.

Your point #2 is edgy: what kind of error? If it is a processing error,
the
request has been, by definition, processed, thus there is no need to
contact another server.
​I suspect 5xx codes might consider the upstream being unavailable,
while
4xx means the request processing has occurred.​

Question 2:
Let say there were 3 backend-server and we are using session persistence
using cookie.
Now assume that 2 of the backed server goes down so niginx will route all
request to 3rd server
Now 2 other server came back online, will niginx use the other 2 server to
route the request even if request have the persistence cookie for 3rd
server.

​It is explicitely said​ ‘​A request that comes from a client not yet
bound
to a particular server […]’. If the 3rd server has been selected
because
it responds correctly, the client will be bound to it, thus it won’t
change
when the other 2 servers come back online.
That represents the added value of having a server-side cookie. On a
basic
load-balancing setup (no way to ‘tie’ a client to a server), the
load-balancing would have resumed connecting the client to the server it
is
supposed to connect to (either following the load-balancing key or
simply
selectin the ‘next’ upstream based on the configured method).

*B. R.*​

On Mon, Jul 27, 2015 at 12:40:04PM +0530, Bhuvan G. wrote:

designated server cannot process a request*, the new server is selected as
if the client has not been bound yet
.

The last line says that

If the designated server cannot process a request.

What does it mean to say “the server cannot process a request.”

it means:
- nginx either failed to contact upstream server and get
response from it (within configured timeouts - see
proxy_*_timeout directives), or some limit was hit (i.e.
max_conns)

- either the response was obtained, but considered inadequate
  and nginx decided not to deliver the answer to client and
  instead try other server (or return an error immediately - see
  nginx.org/r/proxy_next_upstream)

Question 1:
Does it mean the server was down ?
or does it mean server responded with some error code ?
or does it mean that it did not responded in a certain time interval ?
or does it mean that max number of connection limit is reached on that
server ?

in short: this is configurable, see above.

Question 2:
Let say there were 3 backend-server and we are using session persistence
using cookie.
Now assume that 2 of the backed server goes down so niginx will route all
request to 3rd server
Now 2 other server came back online, will niginx use the other 2 server to
route the request even if request have the persistence cookie for 3rd
server.

obviously, not. If a request has a cookie for 3rd server and it is
available, it will be routed to a 3rd server.
Requests without cookies will be routed to servers according load
balancing methods.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs