You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by Linus Brimstedt <li...@viskan.se> on 2015/09/24 12:35:04 UTC
Re: Parallel Deployment: Can I request a specific webapp version?
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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Linus Brimstedt *
CTO
+46 70 - 683 98 54
linus.brimstedt@viskan.se
*Viskan Distanshandel System AB*
Druveforsvägen 8
504 33 Borås, Sweden
+46 33 - 20 60 20
www.viskan.se
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
George,
On 9/24/15 5:59 PM, George Sexton wrote:
> 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?
This is precisely what I was going to suggest: no hacks required. Just
upgrade one server and don't upgrade the rest. If there's a problem,
just roll-back that server or throw it out of the load-balancer.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWBbEeAAoJEBzwKT+lPKRYunkP/Ag4faLEquw6jtPryfN0GKnh
UomV3HVfMs6dQN9QXOMtS3MBHL2e8MxLcM6YmJRjpDYD4Bzqduhvl29RxUkAphPA
gNVbXcB3BcO0Cf7pDqQvuChJNZKoWNui06Kc0jmIIzX6MukAOanZR0O4gh6n1jwH
HreR02sVfkK1jcJ1sIbnW8dDUccVuHzaGeXvC73TKQbvANJVjuzX11ewtrgeS5B7
4kaINlw4LtVP/akBXrVIUh4EudjPRYQ1n84xfjuOGyRXiZQ4LCPIn3+UwzDA6Sre
+pLjU7i35ONi3Y4t/CGqb35xr8/riw1Pg5aWYLksaOWK3idCI8Rf/ELdOC+yEqm1
Qdyb/UYLQuPuffCYiWTVnJcgV0uj8Rv7W/mMY6KrMATkReYSoe2BKBww65C6n2kb
/+Crrs1hWFimLlmSL27BuwmWvZyU+etdKyXO7LxL0pZ/vPJOh1NZuLXzsBEkuIpv
ybbLCpRayZ9T7h/JWFYN7JZ0swutXzGeAdm1mPGp5Gqx3KTUtcJ+j9436ZBQU7Jb
LvzuNsr0H7QPCYy+JBVvV3Lwgl8oDz+jsykIcFQX23cVnyp/+TUUfMcl02j/T4AH
gYO8GJmJRzrkU3zT2I8RlmopWZlvQAKJErHgKEEqTHmzOSXXbAxuAcw/BuKdubFI
XYGp65chClb7R7+FatYg
=7E54
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: [OT] Re: Parallel Deployment: Can I request a specific webapp
version?
Posted by George Sexton <ge...@mhsoftware.com>.
On 9/24/2015 4:27 PM, André Warnier (tomcat) wrote:
> On 24.09.2015 23:59, George Sexton wrote:
> ...
>
>>
>> Couldn't you have your load balancer send x% to one instance, and
>> 1-x% to the other
>> instance?
>
> Wait, I didn't get this.
> Say that x = 20.
> So we send 20% to instance A.
> Then we send (1 - 20)% = -19%, to instance B.
My mistake. I thought most people would interpret my statement as
1.0 - 0.x
Since that isn't the case. I'll be explicit.
Could you have your load balancer send x% to one instance and 100%-x% to
the other instance.
> So together, instance A and instance B handle (20 + -19)% = 1% of the
> clients.
> What happens to the other 99% ?
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
[OT] Re: Parallel Deployment: Can I request a specific webapp
version?
Posted by "André Warnier (tomcat)" <aw...@ice-sa.com>.
On 24.09.2015 23:59, George Sexton wrote:
...
>
> Couldn't you have your load balancer send x% to one instance, and 1-x% to the other
> instance?
Wait, I didn't get this.
Say that x = 20.
So we send 20% to instance A.
Then we send (1 - 20)% = -19%, to instance B.
So together, instance A and instance B handle (20 + -19)% = 1% of the clients.
What happens to the other 99% ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Ludovic Pénet <l....@senat.fr>.
>> You have competing requirements:
>>
>> 1. All servers are the same
>>
>2. Some subset users get a different version of the application
>>
>
>All servers would have all versions of the app, thats the whole point
>:)
>I.e.
>Instead of
>Server 1 - 3: App Version 001
>Server 4 - 6: App Version 002
>
>I would have
>Server 1-6: App Version 001 + 002
>
>Parallel deployment makes this possible and simple to use.
As far as I understand (and use it on a daily basis), parallel deployment allows to upgrade a webapp to a new version with no downtime, new sessions being handled by the newest version and existing ones beinig handled by the version already handling them.
That the only case where I see parallel deployment using multiple versions. And so I see no case where new sessions arr handled by two different versions.
So, it seems to me that // deployment is not a fit for your requirements.
I find them interesting anyway, as I would really like to be able to have a finer control on the selection of the "current" version.
This would allow transparent downgrades, without removing or stopping a version and help solve a stupid problem I had several times : // deployment sort versions alphabetically. So, version 1.1.9 is prefered to 1.1.10, for instance...
Ludovic
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Linus Brimstedt <li...@viskan.se>.
Hi,
Ok, so to conclude this is not possible at the moment.
Thanks for the input and clarifications as well as the suggested ways to
work :)
br
/Linus
On 29 September 2015 at 00:16, Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Linus,
>
> On 9/28/15 2:37 AM, Linus Brimstedt wrote:
> > On 27 September 2015 at 23:55, Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> >>
> >> You have competing requirements:
> >>
> >> 1. All servers are the same
> >>
> > 2. Some subset users get a different version of the application
> >>
> >
> > All servers would have all versions of the app, thats the whole
> > point :) I.e. Instead of Server 1 - 3: App Version 001 Server 4 -
> > 6: App Version 002
> >
> > I would have Server 1-6: App Version 001 + 002
> >
> > Parallel deployment makes this possible and simple to use.
>
> Sure, you can push multiple versions of your application to all your
> servers, but the caveat is that all new users will be using the new
> application: you can't upgrade selected users (like your own QA
> testers, for instance). So this isn't an ideal solution, regardless of
> how simple it is.
>
> >> Sounds like they can't co-exist without some kind of compromise.
> >> We are offering one that works with currently-available
> >> software.
> >>
> >
> > Please elaborate
>
> We've already explained:
>
> 1. Upgrade some load-balanced nodes
> 2. wait (???)
> 3. Profit
>
> If you want your QA team to be able to use the new version of the
> application but none of your "real" users, then try something like this:
>
> 1. Remove N/f from your load-balancer and upgrade using parallel
> deplyment
> (N = # of nodes and f=some factor of nodes you want to use for
> testing)
> (Existing users will still see version V-1 while new users will
> see version V. The lb will not send new users to these servers,
> so nobody will see version V at all.)
> 2. Configure your QA team's browsers so that the lb allows them to
> go to the servers you have upgraded, and get version V
> 3. Proceed with testing
> 4. When you are satisfied, put the nodes from step #1 back into the lb
> normal rotation
> 5. Upgrade the remaining nodes whenever you feel comfortable
>
> This means that, for a time, not all servers are identical. But you do
> achieve your primary objective: blue/green production deployment with
> a private interstitial testing phase.
>
> Your prior use of parallel deployment did not meet your primary
> criterion: namely that it upgrades too many people at once.
>
> I think you have to decide which requirement is more important: the
> private testing phase (which my proposal achieves) or the consistent
> configuration of all servers (which your proposal achieves).
>
> I still believe your requirements are at odds with each other.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWCbxDAAoJEBzwKT+lPKRY1vsP/iu70XKXfhZVM4sTA+VsK220
> keAIjTUESeSKCF3IZoOtMR/xaC+3rsgCGlVjtyS8JOOkQ5/nHvD+e3XktXL8WZo0
> dvynCuFeLFBj89PY3pnDcYnr8AOxnbzlgvKC2dsvE1qKrII1/au9yz3juM2EpO5c
> x4avtBklG7/+8hU7sTjpykOK5/7pMXLv5KsmeX6mzoJJky9f5WXuZ6K20jKc7m2b
> zdjdgXG6hPvwoOh33ybO/vPPx0h0Ih6eflQqhqEblo2xb+XYWCeSTgMwrOR0nXWK
> LXZh2Yyyt7AIozvI1abp97m6kFB9KLSX9QRIb1EmiAnfnkQYCfhWpAPeUcc3ZV/h
> yh2h1qON8bCTeed97GWdpPu9o5l1l4EXIKgOk+iLV4rS0CjMQ/ybl6ePOrGApQs9
> q7vncmX3V4fZGdYf1qXj7ME7RcgE7U+TwRuR40wPB8McU+BVtI3d/S4I5W+9DBF7
> q9+B+EmZ1jCjrwzEot57TuYxM+oT8Lsykm43Esic3CeOxOBdp8phwe65AmZHTxJV
> IIhTOdFuwZzL/n2dZx0dNspjc54Df1dgPoGw0OBa8c8BHPBz8ImskLONBQHZwRvy
> ejwS00Pps7B/DeiquuZLOUilJo4UP5fS8NbpLPMt/5sBb4L9pgQRXs7jFwxQ0A1y
> b6nF/Y5moFILPkWAfuB8
> =w+9s
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Linus Brimstedt *
CTO
+46 70 - 683 98 54
linus.brimstedt@viskan.se
*Viskan Distanshandel System AB*
Druveforsvägen 8
504 33 Borås, Sweden
+46 33 - 20 60 20
www.viskan.se
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Linus,
On 9/28/15 2:37 AM, Linus Brimstedt wrote:
> On 27 September 2015 at 23:55, Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>>
>> You have competing requirements:
>>
>> 1. All servers are the same
>>
> 2. Some subset users get a different version of the application
>>
>
> All servers would have all versions of the app, thats the whole
> point :) I.e. Instead of Server 1 - 3: App Version 001 Server 4 -
> 6: App Version 002
>
> I would have Server 1-6: App Version 001 + 002
>
> Parallel deployment makes this possible and simple to use.
Sure, you can push multiple versions of your application to all your
servers, but the caveat is that all new users will be using the new
application: you can't upgrade selected users (like your own QA
testers, for instance). So this isn't an ideal solution, regardless of
how simple it is.
>> Sounds like they can't co-exist without some kind of compromise.
>> We are offering one that works with currently-available
>> software.
>>
>
> Please elaborate
We've already explained:
1. Upgrade some load-balanced nodes
2. wait (???)
3. Profit
If you want your QA team to be able to use the new version of the
application but none of your "real" users, then try something like this:
1. Remove N/f from your load-balancer and upgrade using parallel
deplyment
(N = # of nodes and f=some factor of nodes you want to use for
testing)
(Existing users will still see version V-1 while new users will
see version V. The lb will not send new users to these servers,
so nobody will see version V at all.)
2. Configure your QA team's browsers so that the lb allows them to
go to the servers you have upgraded, and get version V
3. Proceed with testing
4. When you are satisfied, put the nodes from step #1 back into the lb
normal rotation
5. Upgrade the remaining nodes whenever you feel comfortable
This means that, for a time, not all servers are identical. But you do
achieve your primary objective: blue/green production deployment with
a private interstitial testing phase.
Your prior use of parallel deployment did not meet your primary
criterion: namely that it upgrades too many people at once.
I think you have to decide which requirement is more important: the
private testing phase (which my proposal achieves) or the consistent
configuration of all servers (which your proposal achieves).
I still believe your requirements are at odds with each other.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWCbxDAAoJEBzwKT+lPKRY1vsP/iu70XKXfhZVM4sTA+VsK220
keAIjTUESeSKCF3IZoOtMR/xaC+3rsgCGlVjtyS8JOOkQ5/nHvD+e3XktXL8WZo0
dvynCuFeLFBj89PY3pnDcYnr8AOxnbzlgvKC2dsvE1qKrII1/au9yz3juM2EpO5c
x4avtBklG7/+8hU7sTjpykOK5/7pMXLv5KsmeX6mzoJJky9f5WXuZ6K20jKc7m2b
zdjdgXG6hPvwoOh33ybO/vPPx0h0Ih6eflQqhqEblo2xb+XYWCeSTgMwrOR0nXWK
LXZh2Yyyt7AIozvI1abp97m6kFB9KLSX9QRIb1EmiAnfnkQYCfhWpAPeUcc3ZV/h
yh2h1qON8bCTeed97GWdpPu9o5l1l4EXIKgOk+iLV4rS0CjMQ/ybl6ePOrGApQs9
q7vncmX3V4fZGdYf1qXj7ME7RcgE7U+TwRuR40wPB8McU+BVtI3d/S4I5W+9DBF7
q9+B+EmZ1jCjrwzEot57TuYxM+oT8Lsykm43Esic3CeOxOBdp8phwe65AmZHTxJV
IIhTOdFuwZzL/n2dZx0dNspjc54Df1dgPoGw0OBa8c8BHPBz8ImskLONBQHZwRvy
ejwS00Pps7B/DeiquuZLOUilJo4UP5fS8NbpLPMt/5sBb4L9pgQRXs7jFwxQ0A1y
b6nF/Y5moFILPkWAfuB8
=w+9s
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Linus Brimstedt <li...@viskan.se>.
Hello,
On 27 September 2015 at 23:55, Christopher Schultz <
chris@christopherschultz.net> wrote:
>
> You have competing requirements:
>
> 1. All servers are the same
>
2. Some subset users get a different version of the application
>
All servers would have all versions of the app, thats the whole point :)
I.e.
Instead of
Server 1 - 3: App Version 001
Server 4 - 6: App Version 002
I would have
Server 1-6: App Version 001 + 002
Parallel deployment makes this possible and simple to use.
> Sounds like they can't co-exist without some kind of compromise. We
> are offering one that works with currently-available software.
>
Please elaborate
/Linus
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: GPGTools - http://gpgtools.org
>
> iQIcBAEBCAAGBQJWCGXOAAoJEBzwKT+lPKRYi5sQAJ9A8eJrs4kxIXIECSl/bbtd
> wdEWpDc2QxJ7eZ/o999ZfDfABylZAt0opRGCyqrxt4humh1TJvECWl2HGNiLjdR7
> ciD+4dtjDTCpv7yfEfCJXn4YL60RK35lJ5lXBGsBClmVg2y5vwdqng8KGg/pVotN
> AIe6BHBsiTLuY5Kep6K9RElYPab/71noN/U4j1N12Jf5puKDU+Spbc07Fy5OGsCl
> 5p0s7HsysHeFDiWY9uMIgtF2pJSgoFFF6+S2RHu+wON9m4OciNvZJlh2IYzgM24W
> lJOYm4jqqyHR6Bx3UoXIOFc4HAXwoX13xxPLYbLuILTW7DyFFzkBltTAFqFvC5Fn
> moAGs3jgFqdxlexJ49UjMSO+CCdMCnwvH9zOLM/HDZEN1UItwsCVeU0hiXLC6a8Y
> 5aHjNkLo71IeZq7sjOxw1h/3fMvazbBYwu+VZE//4WKBSaqE//KlKOJBUgPZ2R2R
> S5+MjW97+sgj4wpsZRlt8jmMpcugfn6lWMtpvGj4/NXykoomYnpmsF7cJhgH47S+
> 3fdeRymyw9BnsNvJNULbfjXZoUL9XFpH6WQb5127cYzBrapIYOSoTYn+H/SaeGgi
> pXMJspKz8qb8W9f3yBekQFM7kGcP1cBvp6JTAGwbsTx8VM5oJlffNi7RAVEO6DeV
> IqyVpqOKOnu2GwhpzIs5
> =6+bn
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
--
*Linus Brimstedt *
CTO
+46 70 - 683 98 54
linus.brimstedt@viskan.se
*Viskan Distanshandel System AB*
Druveforsvägen 8
504 33 Borås, Sweden
+46 33 - 20 60 20
www.viskan.se
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Linus,
On 9/27/15 2:41 PM, Linus Brimstedt wrote:
> On 24 September 2015 at 23:59, George Sexton
> <ge...@mhsoftware.com> wrote:
>
> 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?
>>
>>
> Hi
>
> Sure I could. But I like all my servers to be identical. If one
> fails, or is taken out of load balancer due to maintenance, I want
> everything to proceed as if nothing.
>
> I could deploy two different context for this, or use two different
> Tomcats on the same machine, it's just that parallel deployment
> seems like a perfect fit.. except I cannot control the traffic ;)
You have competing requirements:
1. All servers are the same
2. Some subset users get a different version of the application
Sounds like they can't co-exist without some kind of compromise. We
are offering one that works with currently-available software.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJWCGXOAAoJEBzwKT+lPKRYi5sQAJ9A8eJrs4kxIXIECSl/bbtd
wdEWpDc2QxJ7eZ/o999ZfDfABylZAt0opRGCyqrxt4humh1TJvECWl2HGNiLjdR7
ciD+4dtjDTCpv7yfEfCJXn4YL60RK35lJ5lXBGsBClmVg2y5vwdqng8KGg/pVotN
AIe6BHBsiTLuY5Kep6K9RElYPab/71noN/U4j1N12Jf5puKDU+Spbc07Fy5OGsCl
5p0s7HsysHeFDiWY9uMIgtF2pJSgoFFF6+S2RHu+wON9m4OciNvZJlh2IYzgM24W
lJOYm4jqqyHR6Bx3UoXIOFc4HAXwoX13xxPLYbLuILTW7DyFFzkBltTAFqFvC5Fn
moAGs3jgFqdxlexJ49UjMSO+CCdMCnwvH9zOLM/HDZEN1UItwsCVeU0hiXLC6a8Y
5aHjNkLo71IeZq7sjOxw1h/3fMvazbBYwu+VZE//4WKBSaqE//KlKOJBUgPZ2R2R
S5+MjW97+sgj4wpsZRlt8jmMpcugfn6lWMtpvGj4/NXykoomYnpmsF7cJhgH47S+
3fdeRymyw9BnsNvJNULbfjXZoUL9XFpH6WQb5127cYzBrapIYOSoTYn+H/SaeGgi
pXMJspKz8qb8W9f3yBekQFM7kGcP1cBvp6JTAGwbsTx8VM5oJlffNi7RAVEO6DeV
IqyVpqOKOnu2GwhpzIs5
=6+bn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by Linus Brimstedt <li...@viskan.se>.
On 24 September 2015 at 23:59, George Sexton <ge...@mhsoftware.com> wrote:
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?
>
>
Hi
Sure I could. But I like all my servers to be identical.
If one fails, or is taken out of load balancer due to maintenance, I want
everything to proceed as if nothing.
I could deploy two different context for this, or use two different Tomcats
on the same machine, it's just that parallel deployment seems like a
perfect fit.. except I cannot control the traffic ;)
br
/Linus
Re: Parallel Deployment: Can I request a specific webapp version?
Posted by George Sexton <ge...@mhsoftware.com>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
--
George Sexton
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com