
Guillaume Berche
[Retrying with less typing errors, sorry]
+1 for app stickyness when a route is mapped to multiple apps, and sticky sessions are requested (currently through jsessionid cookie).
I'd even suggest that app stickyness is the default when sticky sessions are requested.
What would be use-cases for opting out of app stickyness when sticky sessions are requested ?
I'm not sure either about use cases for an app to control this behavior. If needed to opt-in (eg when sticky sessions are not requested), I'd rather see this as a property of the route controlled by an operator (along with the weight, and potentially mutable/dynamic).
toggle quoted message
Show quoted text
Le 27 mai 2016 11:24, "Guillaume Berche" <bercheg(a)gmail.com> a écrit : +1 for app stickyness when a route us mapped to multiple apps, and sticky sessions are requested (currently through j session is cookie)
I'd even suggest that app stickyness is the default when sticky sessions are requested.
What would be use-cases for opting out of app stickyness ?
I'm not sure either about use cases for an app to control this behavior (ie opt out). If needed, I'd rather see this as a property of the route controlled by an operator (along with the weight, and potentially mutable). Le 27 mai 2016 01:20, "Shannon Coen" <scoen(a)pivotal.io> a écrit :
Yes, thanks for the clarification Mike.
Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.
On Thu, May 26, 2016 at 2:38 PM, Mike Youngstrom <youngm(a)gmail.com> wrote:
Hi Shannon,
Good question. I haven't really considered an app initiating this but I think that could work.
The ultimate use case for this, in my mind, is to eventually support transitioning http sessions from a blue app to a green app in a blue/green deploy type of scenario.
I think this could be done with the a combination of a sticky app feature and the request weight load feature you mentioned in your talk.
With those 2 features I could write my application to indicate to the router that I wish to maintain sticky app. Then I could set request weight to some percent (possibly even 100%) of load to the new app. That way users would eventually and smoothly transition all new http sessions to the new app.
So, to answer your question I think it quite reasonable to ask the application itself, through cookie or something, to declare if it wants instance, app, or no stickiness. However, I believe the mechanism to declare how much load each app bound to a route should get would need to be controlled outside the app, but, could potentially be the very same mechanism you envisioned for the upcoming load weight feature.
Does that make sense?
Mike
On Thu, May 26, 2016 at 11:56 AM, Shannon Coen <scoen(a)pivotal.io> wrote:
Hello Mike,
I thought I'd put this on the list in case others have similar use cases.
At summit you mentioned an interest in a variant of sticky session behavior, and I wonder if you could provide some additional context.
You suggested it would be valuable if, where multiple apps were mapped to the same route, all requests from a client were routed to the same app. I believe the example you gave was where the two apps represent different versions of a web UI. In this case all requests from the client could be load balanced to any instance of the same app, for the life of the session. This might be accomplished using a new cookie.
Do you imagine the application initiating this behavior as it does now? I have some evidence for a feature to relieve apps of this responsibility, by enabling developers to express that sticky sessions should be enabled for a route; then the router could potentially handle returning cookies to clients.
Do you imagine a developer being able to express that they want sticky sessions enabled for a route in either an "app" or "instance" mode?
Thank you,
Shannon Coen Product Manager, Cloud Foundry Pivotal, Inc.
|