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.
That this encoding works with ;jsessionid= as well, so a request to /test.jsp;jsesssionid=cnn8x02mPph_4sOKlbn would go to the third server.
No comments :
Post a Comment