Notice: This resource is no longer being actively maintained and as a result some information may be out of date or inaccurate. Please see for technical instructions or for support related concerns.
RUN@cloud » Session Affinity

Session Affinity

Last modified by Spike Washburn on 2013/02/27 18:51

Session affinity (also called "sticky sessions") is an option you can turn on when you need users to be routed to the same application instance for each request. 

The default behavior for CloudBees is to allocate requests in a round robin fashion to backends that are available - as evenly as possible (according to the routing layer) - this is ideal as it means that servers can come and go quickly in accordance with load, and ensure that requests are processed smoothly. However, not all applications work optimally this way (or at all). Many frameworks prefer that sessions/requests are "sticky" - ie once allocated to a back end - it stays with that back end - some examples of this are Lift, Grails (to some extent) - probably many others. 

Enabling Sticky Sessions

To enable this, next time you deploy, append "stickySession=true" to your deploy command: 

$ bees app:deploy -a account/app application.war stickySession=true 

You should only need to do that once, subsequent deploys will remember it.

If you with to apply this to an app you have running, you only need to do this once:  

$ bees app:update -a account/app stickySession=true** 

This is only available for some plans - please consult the pricing page for details: (RUN Services tab)

Understanding round-robin routing (standard)

In this case, requests are allocated to each backend as they come in (in a balanced way); 


Understanding sticky session routing

With sticky sessions, when a client is first allocated to a backend (which happens similarly to round robin) it will stay bound to that back end. Routing is based on a "route" cookie that is set for the client, which the client sends back to the server for each subsequent request.  If the backend app instance becomes unreachable the client will be re-assigned a route cookie for a working server. 


~** If you need this enabled for an existing SSL router and it isn't already working for you - please do raise a support ticket. 

Application Session Stores

Even with Sticky Session routing enabled, it is possible for clients to be re-routed to app instances if the app server becomes unreachable. To keep clients from seeing loss of session data if it gets re-routed, it is suggested that apps use an  Application Session Store.  This also makes updates that you make to your apps (via app:deploy) transparent to your connected clients.

Created by Michael Neale on 2012/02/13 04:49