Nginx response with persistence session and backend server failure

[B.R.]

On Mon, Jul 27, 2015 at 9:10 AM, Bhuvan Gupta <bhuvangu at gmail.com> wrote:

> 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 ?
>
​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.*​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150727/d6cd1565/attachment.html>