Leveraging sticky sessions for application instances

Purpose

The documentation in this section is intended for developers interested in leveraging sticky sessions for application instances deployed on Pivotal Platform.

Goal

This section illustrates the sticky session flow that Pivotal Platform supports out of the box.

Sticky Sessions

Pivotal Platform supports session affinity or sticky sessions for incoming HTTP requests to applications if a jsessionid cookie is used.

If multiple instances of an application are running on Pivotal Platform, all requests from a given client will be routed to the same application instance.

This allows application containers and frameworks to store session data specific to each user session.

When a user session that was sticky to a crashed or stopped instance makes another HTTP request, the request is routed to another instance of the application.

Session data that must be available after an application crashes or stops, or that needs to be shared by all instances of an application, should be stored in a Pivotal Platform service.

There are several open source projects that share sessions in a data service.

Behind the scenes

When the first request reaches the Pivotal Platform the router checks for the '__VCAP_ID__' cookie

If the cookie is found, the request is routed to the application instance that served the previous request

If the cookie is missing, the request is routed to an application instance, and before the response is returned to the client, the router populates the '__VCAP_ID__' cookie and has the information of the application instance

NOTE: Cloud Foundry does not persist or replicate HTTP session data. If an instance of an application crashes or is stopped, any data stored for HTTP sessions that were sticky to that instance are lost.

Solution

If the applications have multiple requests sent back and forth from the an application to the REST Services in a single transaction, then the application needs to honor the '__VCAP_ID__', and should copy the cookie from the response and set it in the subsequent requests. This way, the requests will always be routed to the same REST Service Application instance.