A Quick Tour of the Cloud Foundry Router and Sticky Sessions

The Cloud Foundry Router is a key component of the platform that provides:

• load balancing to multiple instances of applications with a dynamic routing table updated in a fraction of a second every time there is a change in the system
• sticky session support
• access log for apps that feeds into an application's Loggregator stream
• support for Web Socket and other TCP protocols via HTTP Connect

Cloud Foundry has had support for "sticky" sessions in both v1 and v2. This week I had a meeting with a very large technology provider that has been using Cloud Foundry for quite awhile. They had no idea that sticky sessions were supported or how they worked and I realized we should have a better explanation and showcase of this capability. The use-case for this scenario involved a significant performance optimization when using sticky sessions because of user-specific data caching in the warmed-up app instance.

To enable Cloud Foundry sticky sessions all you need to do in the application is set a cookie named JSESSIONID. Java web applications have a history of using a cookie named JSESSIONID when you enable a session with code like request.getSession( true ) and because many Cloud Foundry users run Java apps, the project decided to use JSESSIONID as an indicator that sticky sessions should be used. To use another sticky sessions with another language like Ruby or Node.js, all you need to do is set a cookie named JSESSIONID and Cloud Foundry will attempt to consistently route requests to the same app instance.

I created a simple Java web application to show how this works and I hosted a copy of it on http://sticky-session.cfapps.io. In the first screenshot you can see that sticky sessions are not enabled. First we can see that there are 4 instances of the app running.


Now when we visit the app and use something like Chrome Dev Tools to inspect the app. Refresh the app several times and observe that the printed out port changes as we are load balanced across the multiple app instances.

Now we'll click the "start a sticky session" link in the app, which creates a Java session in Tomcat and creates a JSESSIONID cookie. The router will notice the JSESSIONID cookie and set a Cloud Foundry specific cookie named __VCAP_ID__ with a value of the app instance GUID. The __VCAP_ID__ cookie is the hint to the router to send the request to the specific app instance. With these cookies set, refresh the page and the browser should consistently route to the single app instance.

If you use Chrome Dev Tools to delete the __VCAP_ID__ cookie and refresh the page, and you should see a randomly selected app instance value get set again for __VCAP_ID__. Subsequent page refreshes will be sticky to the instance reflected in the updated __VCAP_ID__ cookie value.

If you are interested in other features for the Cloud Foundry Router, let us know on the Cloud Foundry mailing list.