Re: Parallel Deployment: Can I request a specific webapp version?

[Linus Brimstedt]

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?

[Ludovic Pénet]

>> 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?

[Linus Brimstedt]

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?

[Christopher Schultz]

-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?

[Linus Brimstedt]

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?

[Christopher Schultz]

-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?

[Christopher Schultz]

-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?

[George Sexton]

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

Re: Parallel Deployment: Can I request a specific webapp version?

[Linus Brimstedt]

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?

[George Sexton]

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

[OT] Re: Parallel Deployment: Can I request a specific webapp version?

[tomcat]

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?

[Chris Gamache]

+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 hartmut.honi...@gmail.com 
 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?

[Christopher Schultz]

-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?

[Christopher Schultz]

-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?

[chris derham]

 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?

[Christopher Schultz]

-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-mail: users-h...@tomcat.apache.org

Re: Parallel Deployment: Can I request a specific webapp version?

[Konstantin Kolinko]

2015-07-19 22:49 GMT+03:00 Hartmut Honisch hartmut.honi...@gmail.com:
 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