Session Affinity not working

[sterankin]

Issue

Session Affinity/Sticky sessions are not working.

Context

I have added the following section sticky_session_cookie_names to the manifest file which looks something like:

applications:
  - name: myapp
    routes:
      - route: ${name}.us-east-1.np.com
    instances: 2
    memory: 4096M
    timeout: 600
    router:
      sticky_session_cookie_names: [ "_myapp_session" ]
    buildpacks:
      - ruby
    stack: cflinuxfs3
    env:

Traffic Diagram

           +----+---+    +----------+     +-------+
  \o/      |        |    |          |     |       |
   +  +--->+ AWS LB +--->+ Gorouter +---->+  App  |
  / \      |        |    |          |     |       |
 client    +--------+    +----------+     +-------+

Expected result

I would expect session affinity to work and the VCAP_ID to be visible in the headers or cookie as per:
https://docs.cloudfoundry.org/concepts/http-routing.html#sessions

Current result

There is no VCAP_ID in the cookies and the user is still redirected to different instances of the app

Additional Context

Since this is a Ruby on Rails app, we are setting the session store as follows when the app initialises. I assume this has to match the sticky_session_cookie_names set in the manifest.

Rails.application.config.session_store :cookie_store, key: '_myapp_session'

[domdom82]

hi @sterankin the sticky_session_cookie_names is a property that is set on a platform level

this means you define it centrally and it will be used for all apps that you push. it can also be multiple names as it is an array. the default value is "JSESSIONID" as it is the most commonly used name for session cookies.

once you have set this value in your CF deployment (not your app manifest) it will be visible globally.

you can then push an app that sets your cookie name, e.g. _myapp_session and Gorouter will set a matching VCAP_ID cookie for it.

[domdom82]

@ameowlia tbh I never quite understood why this can't be configured on a per-app basis. the name of session cookies is very app-specific even though most use JSESSIONID.
IMO we should think about adding that info to the app manifest and push it via NATs as route info to gorouter. technically, gorouter would be able to use different session cookies for different apps.

[sterankin]

@ameowlia tbh I never quite understood why this can't be configured on a per-app basis. the name of session cookies is very app-specific even though most use JSESSIONID. IMO we should think about adding that info to the app manifest and push it via NATs as route info to gorouter. technically, gorouter would be able to use different session cookies for different apps.

For example see this link: https://stackoverflow.com/questions/30625748/what-are-the-names-of-session-ids-for-python-and-ruby

Ruby on Rails uses a session cookie name which has the application name, e.g. myapp_session

It would be much better to be able to overwrite this at an app level. Imagine an organisation who had dozens or hundreds of apps which may have different session cookie names, it would be a pain to have to add them all to the sticky_session_cookie_names array in the cf deployment manifest. In fact, I have no idea where that manifest will even live since I would not have visibility to it as an app developer in a large org.

[ameowlia]

I agree. There are many things set at the foundation level that make sense for an app to be able to override. The real answer is: it is waaaaaaaay easier and faster to get features out if you only need them at a foundation level.

If anyone wants to take on the work to make this configurable per app, I am happy to review PRs.

[domdom82]

There is a slack discussion starting about how to make such user-defined things easier to add. I tend towards closing this issue in favor of a broader story that enables user-defined route options. This will also be needed for the upcoming change that makes the load balancing algorithm configurable per route.

[MarcPaquette]

@ameowlia & @sterankin,
Any issues with closing this out in favor of the creation of the broader story that @domdom82 suggested?

[maxmoehl]

We have that broader story already, it's now written out in RFC0027.

This particular feature probably won't make into the initial implementation round but it is a good candidate to be tackled once the base is in place. I'd say we can keep this issue around until it is actually fixed.