Hello, Opening an old thread here regarding controlling which version of a web app a request ends up at in a parallell deployment scenario.
My use case: I would like to use parallel deployments for A/B testing. I.e, deploy new version. Send x% of visitors to the new version, the rest to the old one. Once conviced the new version is better, have traffic go primarily to the new version and let the old one die. Next deploy, samt all over again. Someone mentioned controlling this through a cookie, however, when I was checking my browsers requests I could find no signs of a cookie controlling this (other than the normal session cookie, but in this case i suppose this is meta data baked into the session ? Could find my way around the code to verify this) Im not opposed to do some development here if there is not support already and it would be approved. I would then prefer to control the behaviour through a header which I can impose in a load balancer or proxy fronting Tomcat. Other suggestions are welcome. (related question on serverfault: http://serverfault.com/questions/723944/can-you-redirect-a-user-to-a-specific-version-in-tomcats-parallel-deployment ) br /Linus On 21 July 2015 at 19:21, Christopher Schultz <ch...@christopherschultz.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > Chris, > > On 7/21/15 11:07 AM, Chris Gamache wrote: > > +1 here. This would be nice to have a standard way to manage > > different logical versions of the same webapp to handle > > split-braining client and server code. That's my million dollar > > problem. > > > > So, the idea floated by this fine group of list participants was > > to deploy and use cookies that a reverse proxy would decode to send > > your users to different back ends. That only gets you halfway to > > where you're going. Say you have version 1.0 and 1.1. Any patches > > not requiring reload could be deployed with #001,#002, but you > > would need to deploy two or more of the same webapp to get > > different urls: /webapp-1.0 and /webapp-1.1. The whole idea of the > > parallel deployment is to get the old version of the webapp > > undeployed asap. If you have different logical versions that need > > to remain... Well, using the management servlet you can > > programmatically undeploy your obsolete webapps at your leisure. > > > > I'm sure there's always a better idea lurking around out there > > though. > > I'm still not understanding the use case, here. > > In what scenario would you want to knowingly access an "older" version > of the web application than the latest, and at the same time *not* have > a session key that is valid in one of those older versions? > > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: GPGTools - http://gpgtools.org > > iQIcBAEBCAAGBQJVrn+UAAoJEBzwKT+lPKRY2fsQAKHgUSE2Q5MvW3IjuKKcoMDv > mh8E++zeMBRV9OqAX3CF6YcmtT8Fq7Fgd8U5dn2PyMw9hwq2YBIi4OuvZmD9Jre0 > CVLG+2x/RaxrkSiJJQpwqYiFW69ZZ8cf7SgSTeqzaZS9f14VpXFISgSCOGYRyEBH > Cm6BiKzO96//cmk17/rYhkOsDt+6rKIsfRv3KNwSujxfzcPJ1ayohYvchc5njaTi > A3KSzfy65UbUybgP82OX+cV25+78dVMG+ndUoKLwukvDxY8Lh63xBhlYh7pxhtcU > N3XD7JgaNxzpsyX2OxkKD+3BCJ2t7Gx0ZqYn3bFvOdRgCORGnOZCwoRPWc5ATmuh > B/TWkamzvZgXgUfMewoJL3lmcQPlltw9SbXAUGssg9tas5foiFKjxHRR47hJMfju > m6xRgYRw1YY9DbfFKaP82ybglfBcO1+K9lnCOFBmzsC73Kvkqaq+XNR+K0EOg3bY > wF2rRqkikNg0PcrhmwdMMpP21kY1nDBr9h1fDzS3emguVKKEGnLjz/YfJ9QX/wo5 > IztmdgvvodMwJpY8lSQxOStgKcAbyt/fjZ1XvqLWxMVRldnuYxFIKzXwFOdN8TfO > +N5Vz6tGeX3xviFpYCCJ8tTqYbxJl4iWkpqGZneY4wAXRFSkwl7XCPz4Q/4FkbRv > omi/s7IsQ+f0Il7KPY+S > =Gcmi > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > -- *Linus Brimstedt * CTO +46 70 - 683 98 54 linus.brimst...@viskan.se *Viskan Distanshandel System AB* Druveforsvägen 8 504 33 Borås, Sweden +46 33 - 20 60 20 www.viskan.se
