Sticky session
From Resin 3.0
(renamed tag to directive) |
|||
| (One intermediate revision by one user not shown) | |||
| Line 5: | Line 5: | ||
In a clustered configuration, the [[Clustering and Load Balancing|load balancer]] sends requests to multiple backend Resin servers. Each session has an owning Resin server and a backup Resin server. The load balancer will send a session's request to the owning server or to the backup if the owning server is not available. The association of a session with a backend server is called "sticky sessions". | In a clustered configuration, the [[Clustering and Load Balancing|load balancer]] sends requests to multiple backend Resin servers. Each session has an owning Resin server and a backup Resin server. The load balancer will send a session's request to the owning server or to the backup if the owning server is not available. The association of a session with a backend server is called "sticky sessions". | ||
| − | Because the load balancing occurs before any interpretation of the [[Virtual Host]] or [[Web Application]], it's a <[[server]]> configuration variable, with the <[[session-cookie]]> | + | Because the load balancing occurs before any interpretation of the [[Virtual Host]] or [[Web Application]], it's a <[[server]]> configuration variable, with the <[[session-cookie]]> directive. |
== Sticky Session encoding == | == Sticky Session encoding == | ||
Latest revision as of 20:23, 21 February 2006
Sticky sessions work with the load balancer to improve efficiency of Persistent Sessions in a clustered configuration.
In a clustered configuration, the load balancer sends requests to multiple backend Resin servers. Each session has an owning Resin server and a backup Resin server. The load balancer will send a session's request to the owning server or to the backup if the owning server is not available. The association of a session with a backend server is called "sticky sessions".
Because the load balancing occurs before any interpretation of the Virtual Host or Web Application, it's a <server> configuration variable, with the <session-cookie> directive.
Sticky Session encoding
Sticky sessions encodes the session cookie with the owning server. The encoding using a simple prefix value. 'a' refers to the first server in the cluster, 'b' refers to the second server, ..., 'z' refers to the 26th server.
So the session cookie JSESSIONID=cnn8x02mPph_4sOKlbn would go to the third server, 192.168.0.12 in the following configuration
<cluster> <srun id="a" host="192.168.0.10" port="6802"/> <srun id="b" host="192.168.0.11" port="6803"/> <srun id="c" host="192.168.0.12" port="6803"/> </cluster>
Note that this encoding works with ;jsessionid= as well, so a request to /test.jsp;jsesssionid=cnn8x02mPph_4sOKlbn would go to the third server.
