Re: Parallel Deployment: Can I request a specific webapp version?
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 < ch...@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 < > > ch...@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-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
Re: Parallel Deployment: Can I request a specific webapp version?
-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 < > ch...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
>> 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
Hello, On 27 September 2015 at 23:55, Christopher Schultz < ch...@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-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
Re: Parallel Deployment: Can I request a specific webapp version?
-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 > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
On 24 September 2015 at 23:59, George Sexton 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?
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Re: Parallel Deployment: Can I request a specific webapp version?
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-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
[OT] Re: Parallel Deployment: Can I request a specific webapp version?
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
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 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
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 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
Re: Parallel Deployment: Can I request a specific webapp version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Chris, On 7/21/15 1:30 PM, chris derham wrote: >>> BTW: The reason I'm asking is because that transparent shift >>> from one app release to the next doesn't play along well with >>> any caches (browser, caching proxies, CDNs etc.): When a shift >>> to the next app release occurs, I generally need the client >>> browsers to fetch a fresh copy of all files belonging to that >>> release. And the only way to force them to do that is by having >>> them use a different URL than for the old app release files.. >> >> Or, you could use proper proxy-friendly cache-control response >> headers for those resources. Why aren't you doing that? > > The OP's main thread here is asking about logical deployment. > However as a sub-thread he is asking about caching. As Christopher > replied in this thread, I will attempt to clarify what I think the > OP is asking. > > If you have v1.0.0 of the app deployed, and it has sent cache for > 1 day replies for javascript/image/css files, then this works > fine. However as soon as you release the next version, the browsers > won't send requests as they have a local cache. Christopher's reply > was "use proper proxy-friendly cache-control response headers". IMO > having the browser only query for such static resources as these > daily is something that would be required to reduce calls. However > this comes at the expense of causing this issue. Of course. > My first thought was to suggest that the OP somehow use ETag > header combined with a version number. However if the browser is > told to cache for 1 day, this won't work. Having said that, if your > app did send an ETag which was a hash of the files contents, then > it would auto download a new version if it had changed between > v1.0.0 and v1.0.1. The ETag won't help if the browser is convinced that the resource should not go stale in the next e.g. 24 hours: the browser won't even make a HEAD request for that resource, or a conditional-GET with an If-Last-Modified header set. The user would have to do a full-refresh (usually SHIFT-CTRL-R or equivalent) to re-check the ancillary files e.g. .css, .js, etc. > I think that this leaves 3 solutions > > 1) Gauge what your site can support in terms of many calls to > static resources vs when a new version is rolled out. Perhaps a 5 > minute browser cache is ok. Or 60 mins. or 180 etc. It is a > balancing act between reducing server calls for static content that > hasn't changed and the time for an upgrade to appear in the > browser > > 2) Adjust the source of the website such that each script/css/img > tag contains a version number parameter. You could do this via > pre-processing the source rather than manually. Then cache that > for 365 days. If you release a new version, just update the > number. This is probably the best way to deal with files that have a true "version" to them: once you sundown one version, you create a new URL for the new version, etc. But for things like .css, I think it's probably not necessary. We have some GWT-based components where the version number of the .js files is very important, and the browser can't just use the old version of the script with new data and vice-versa. So we do version those URLs, but it's not done at the context-path level.. it's done at the resource level. So, something like this: /context/path/to/js/my-awesome-tool.1.4.2.js Then this doesn't even have anything to do with the current version(s) available in parallel deployment. It also means that it will work if you want to offload your static files to another server that knows nothing about parallel deployment. > 3) Set a cookie with the version number, and then redirect server > side to different version specific urls. Yuck. > 2) seems to be the most robust to me. Christopher can you clarify > what you meant? I agree that #2 is probably best, but it depends on the circumstances. - From what I've read here, I'd stick with #2. - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrqaeAAoJEBzwKT+lPKRYQxAQAJS/JImeo2FVFi7qwavqnTXb MZJfxSBIJsGNaWryTdGo0MtVXN2vCcvL3Wnhsa71Vp80g5iyUs5Wc2GBMgTRr4fQ mYMMST3c2yu1TZl1kGa91d86eBFzBwEKp1Qb12/GI7iDTArtwHpkVWhNErVvheex dHQcMzWTfcsRzxYBHtWGTXlyd+JtsRdjOPooykTznsRslQuQFvwFMVUyBHEAWmba XH9Wu2SK3SdTjsAdyXgYQYuqryEKts5SFV6zfkXoK9P8Z3nt/vZGZlHJJj0fcq/I KY6gQeoNfs3JaGqwYJ2NAlr3oduziSB5aC1FuP5mPupQ/dsXGsx9a3WKOTnAL+XU cSRMS41BSU3oWq40CwbqRhZ1/iDzmq0A5VypMTHobABflHPY48DzEZxzAHyb0Pms B0iJ5IwHhdoaHcvyyTdx+LXfD6pIf+eKc8GIBqRYpZf1fFyQtNTpvJjjkSNxHPTW Am+rHUDI5Z2tBEYOdkmrHm80hCfG6v6My/zv9BuDxY90CBGHwIv6BkKLRWDD0MAe 8vrgPwUy+xbBFwRmli3UnVd77XE7DKw2o3Q+VCVMnUm7mwLEY2+QtvCP8nESloBp 53vgfxNUCBr4QnX7FSpIjey38uHgIIbPwA9pZGWeW6dhfVLU1bE1P8muJldU4Zni iZjdXgDNB0GOssdI3EEv =55bt -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-m
Re: Parallel Deployment: Can I request a specific webapp version?
>> BTW: The reason I'm asking is because that transparent shift from >> one app release to the next doesn't play along well with any caches >> (browser, caching proxies, CDNs etc.): When a shift to the next app >> release occurs, I generally need the client browsers to fetch a >> fresh copy of all files belonging to that release. And the only way >> to force them to do that is by having them use a different URL than >> for the old app release files.. > > Or, you could use proper proxy-friendly cache-control response headers > for those resources. Why aren't you doing that? The OP's main thread here is asking about logical deployment. However as a sub-thread he is asking about caching. As Christopher replied in this thread, I will attempt to clarify what I think the OP is asking. If you have v1.0.0 of the app deployed, and it has sent cache for 1 day replies for javascript/image/css files, then this works fine. However as soon as you release the next version, the browsers won't send requests as they have a local cache. Christopher's reply was "use proper proxy-friendly cache-control response headers". IMO having the browser only query for such static resources as these daily is something that would be required to reduce calls. However this comes at the expense of causing this issue. My first thought was to suggest that the OP somehow use ETag header combined with a version number. However if the browser is told to cache for 1 day, this won't work. Having said that, if your app did send an ETag which was a hash of the files contents, then it would auto download a new version if it had changed between v1.0.0 and v1.0.1. I think that this leaves 3 solutions 1) Gauge what your site can support in terms of many calls to static resources vs when a new version is rolled out. Perhaps a 5 minute browser cache is ok. Or 60 mins. or 180 etc. It is a balancing act between reducing server calls for static content that hasn't changed and the time for an upgrade to appear in the browser 2) Adjust the source of the website such that each script/css/img tag contains a version number parameter. You could do this via pre-processing the source rather than manually. Then cache that for 365 days. If you release a new version, just update the number. 3) Set a cookie with the version number, and then redirect server side to different version specific urls. 2) seems to be the most robust to me. Christopher can you clarify what you meant? HTH Chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
-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
Re: Parallel Deployment: Can I request a specific webapp version?
+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. CG > On Jul 19, 2015, at 3:49 PM, Hartmut Honisch > wrote: > > Hi everyone, > > I'm using Tomcat's parallel deployment feature, and I wonder whether > there's a way to request a specific version of my webapp. > > Let's say I have a WAR named myapp##001.war deployed on my server and just > deployed a new WAR myapp##002.war. > Requests to http:/myserver/myapp/.. are transparently mapped by Tomcat to > version 001 for existing sessions and to version 002 for new sessions. > > Is there a way to explicitly request version 001, like > http://myserver/myapp##001/...? That specific syntax obviously doesn't > work, otherwise I wouldn't be asking :) > > BTW: The reason I'm asking is because that transparent shift from one app > release to the next doesn't play along well with any caches (browser, > caching proxies, CDNs etc.): > When a shift to the next app release occurs, I generally need the client > browsers to fetch a fresh copy of all files belonging to that release. And > the only way to force them to do that is by having them use a different URL > than for the old app release files.. > > So my idea is to have the browser make an initial request to > http://myserver/myapp/redir.do, when launching the app, which > instantaneously redirects to the actual release-specifc URL > http://myserver/myapp##00x/... , thereby having the browser use > release-specific URLs for all application files. > > Any help is appreciated. > Thanks > - Hartmut - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hartmut, On 7/19/15 2:49 PM, Hartmut Honisch wrote: > Hi everyone, > > I'm using Tomcat's parallel deployment feature, and I wonder > whether there's a way to request a specific version of my webapp. > > Let's say I have a WAR named myapp##001.war deployed on my server > and just deployed a new WAR myapp##002.war. Requests to > http:/myserver/myapp/.. are transparently mapped by Tomcat to > version 001 for existing sessions and to version 002 for new > sessions. > > Is there a way to explicitly request version 001, like > http://myserver/myapp##001/...? That specific syntax obviously > doesn't work, otherwise I wouldn't be asking :) > > BTW: The reason I'm asking is because that transparent shift from > one app release to the next doesn't play along well with any caches > (browser, caching proxies, CDNs etc.): When a shift to the next app > release occurs, I generally need the client browsers to fetch a > fresh copy of all files belonging to that release. And the only way > to force them to do that is by having them use a different URL than > for the old app release files.. Or, you could use proper proxy-friendly cache-control response headers for those resources. Why aren't you doing that? - -chris -BEGIN PGP SIGNATURE- Comment: GPGTools - http://gpgtools.org iQIcBAEBCAAGBQJVrmCLAAoJEBzwKT+lPKRYmesP/itMThqJeB6kRl5kWgedsbG1 RSO+SyM2BqgP+BfdVtk2UR7CX3v4YuOV0TWPM0VgCnfhqh/lMS6gASUwNDW1FKd1 /Q0SterbKn7RDTzJ2GiYT1A2PF78iNDZ3ZjKMvJ2wlTv7QLcVyetFO8V+lWXOIKG xeaKP7hPAh9pau4FCrcwFeFrikdLpHly7BubUGehFpeINVFe30mpbosLXvR6cSq+ P9N/mAqNL+lVCnv7xuU3U7HzEoFfTUWWA/W+qxMgtnZ8bK2om7xAPpOLwo2lwXKu 9rOSFd1Q1/nP5Aa8Jqb+fCrbBXB8Z6yURJkucDTvBWCkP5VetJWbJOUYCmqYz0BG nueFOR09pvIWcEwMUHyJquaYz/PEJx5GEa6qmo1zB21MdekmG+zxI/70pdJ8FGH7 LT7JcEO3kRuRetYrVCVVpDLooG4LROz67LhErXc/U6AnykuT8rpWjT35gRPA2nw9 01cbKpdFfJvJIOdiuskuD3Bq948NS16DuPzSMIteI7KR2RpFFQMHW9+hG9KFv1oa jTElNAFzo5nKT1TrVXN4bFanMwIKqL64YBPyvnFaJBMojiN4ehD4jFgTmqnMzJ0C 7wshZ9TmONiRkQC5Hvlyp6Ct9Bn8GyZyPd/Pet9MGZL7h+JIler0JbJ1yhr21J3D jWklqKlrKvtrjRzRkLn9 =7BkU -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Parallel Deployment: Can I request a specific webapp version?
2015-07-19 22:49 GMT+03:00 Hartmut Honisch : > Hi everyone, > > I'm using Tomcat's parallel deployment feature, and I wonder whether > there's a way to request a specific version of my webapp. > > Let's say I have a WAR named myapp##001.war deployed on my server and just > deployed a new WAR myapp##002.war. > Requests to http:/myserver/myapp/.. are transparently mapped by Tomcat to > version 001 for existing sessions and to version 002 for new sessions. > > Is there a way to explicitly request version 001, like > http://myserver/myapp##001/...? That specific syntax obviously doesn't > work, otherwise I wouldn't be asking :) No. Routing (mapping) is based on session identifier. If you can supply a valid session identifier (cookie) for an older version of web application, you will be routed to the old version. Otherwise, you get the latest version of the web application. > BTW: The reason I'm asking is because that transparent shift from one app > release to the next doesn't play along well with any caches (browser, > caching proxies, CDNs etc.): > When a shift to the next app release occurs, I generally need the client > browsers to fetch a fresh copy of all files belonging to that release. And > the only way to force them to do that is by having them use a different URL > than for the old app release files.. > > So my idea is to have the browser make an initial request to > http://myserver/myapp/redir.do, when launching the app, which > instantaneously redirects to the actual release-specifc URL > http://myserver/myapp##00x/... , thereby having the browser use > release-specific URLs for all application files. http://www.w3.org/Provider/Style/URI.html Cool URIs don't change If you need to force reload of a script of a css, a usual trick is to append a query (with some app version token calculated at build time) to the file path. I mean, the path to CSS / JS file in HTML text produced by your web application. There may be also some other schemes to embed version token in path to those files and use RewriteValve or similar solution to strip away the version token. http://tomcat.apache.org/tomcat-8.0-doc/rewrite.html Best regards, Konstantin Kolinko - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Parallel Deployment: Can I request a specific webapp version?
Hi everyone, I'm using Tomcat's parallel deployment feature, and I wonder whether there's a way to request a specific version of my webapp. Let's say I have a WAR named myapp##001.war deployed on my server and just deployed a new WAR myapp##002.war. Requests to http:/myserver/myapp/.. are transparently mapped by Tomcat to version 001 for existing sessions and to version 002 for new sessions. Is there a way to explicitly request version 001, like http://myserver/myapp##001/...? That specific syntax obviously doesn't work, otherwise I wouldn't be asking :) BTW: The reason I'm asking is because that transparent shift from one app release to the next doesn't play along well with any caches (browser, caching proxies, CDNs etc.): When a shift to the next app release occurs, I generally need the client browsers to fetch a fresh copy of all files belonging to that release. And the only way to force them to do that is by having them use a different URL than for the old app release files.. So my idea is to have the browser make an initial request to http://myserver/myapp/redir.do, when launching the app, which instantaneously redirects to the actual release-specifc URL http://myserver/myapp##00x/... , thereby having the browser use release-specific URLs for all application files. Any help is appreciated. Thanks - Hartmut