On 9/24/2015 4:35 AM, Linus Brimstedt wrote:
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.
Couldn't you have your load balancer send x% to one instance, and 1-x%
to the other instance? Why would Tomcat even have to be aware of this?
(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
--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
