# Nginx response with persistence session and backend server failure **URL:** \ **Category:** NGINX\ **Created:** [July 27, 2015, 9:10am UTC](https://www.ruby-forum.com/t/nginx-response-with-persistence-session-and-backend-server-failure/242790 "2015-07-27T09:10:50Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Rafa\_F](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/958977/32.png) [@Rafa\_F](https://www.ruby-forum.com/u/Rafa_F)\ **Post date:** [July 27, 2015, 9:10am UTC](https://www.ruby-forum.com/t/nginx-response-with-persistence-session-and-backend-server-failure/242790/1 "2015-07-27T09:10:50Z")
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](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 ---
**Author:** ![Bhuvan\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7bcc69/32.png) [@Bhuvan\_G](https://www.ruby-forum.com/u/Bhuvan_G)\ **Post date:** [July 27, 2015, 7:30pm UTC](https://www.ruby-forum.com/t/nginx-response-with-persistence-session-and-backend-server-failure/242790/2 "2015-07-27T19:30:38Z")
On Mon, Jul 27, 2015 at 9:10 AM, Bhuvan G. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.\*​ ---
**Author:** ![Bhuvan\_G](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/b/7bcc69/32.png) [@Bhuvan\_G](https://www.ruby-forum.com/u/Bhuvan_G)\ **Post date:** [July 27, 2015, 8:03pm UTC](https://www.ruby-forum.com/t/nginx-response-with-persistence-session-and-backend-server-failure/242790/3 "2015-07-27T20:03:21Z")
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.