Sticky sessions

From Resin 3.0

Revision as of 11:31, 30 November 2005 by Ferg (Talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


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> tag.

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.

Personal tools