Customizable parallel deployment

[Tomáš Bleša]

As I understand tomcat documentation, parallel deployment is intended to be used to smoothly rollout new versions of webapp. I've looked in source code and it's written such that there is probably no way to custimize selection of proper context version. If session is invalid then newest version is always selected.
I wonder if it would be desirable to build in more flexibility in context selection process. For example consider following scenario (real one in my company). We develop complex CRM system and one ROOT.war is used by multiple customers. Each customer has special ID that has to be part of URL address:

site.com?customer=A
site.com?customer=B
...
All customers A, B, C, ... use the same version 5.x of our app. Now we have version 6 with massive changes in UI (+external API) and we want to gradually move our customer base (with their consent) from version 5 to version 6. We cannot afford to migrate all customers to v6 at once. Giving each of our customers unique URL (a.site.com, b.site.com, ...) and use virtual hosting is technically possible but it would complicate other things in our infrastructure.

What I would like to accomplish is to have multiple versions of the app, e.g.:
ROOT##571.war
ROOT##572.war // hotfix of 5.7.1
ROOT##573.war // hotfix of 5.7.2
ROOT##600.war
ROOT##601.war // hotfix of 6.0.0

and two-step process of context version selection.
Step 1)
Belong the request to customer with version 5? -> pre-select ##571, ##572, ##573
Belong the request to customer with version 6? -> pre-select ##600, ##601
Done by my custom ContextVersionSelector interface implementation (which of coarse would check "customer" param in URI)
Step 2)
Use StandardContextVersionSelector on results from previous step (current behavior ... it would be used always as last applied selector)

If I understand the code right, all context selection magic is done in Mapper.java (which is now declared final) and it would have to be modified to support customizable version selection.

My questions are:
Is there a better way how to accomplish "slow pace" rollout of new version? (I mean with just Tomcat and nothing more)
If not, do you consider my proposed Mapper imrovement interesting/useful? (I can try pull request)

Thanks
Tomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org

[Mark Thomas]

Post by Tomáš Bleša
As I understand tomcat documentation, parallel deployment is intended to be used to smoothly rollout new versions of webapp. I've looked in source code and it's written such that there is probably no way to custimize selection of proper context version. If session is invalid then newest version is always selected.
site.com?customer=A
site.com?customer=B
...
All customers A, B, C, ... use the same version 5.x of our app. Now we have version 6 with massive changes in UI (+external API) and we want to gradually move our customer base (with their consent) from version 5 to version 6. We cannot afford to migrate all customers to v6 at once. Giving each of our customers unique URL (a.site.com, b.site.com, ...) and use virtual hosting is technically possible but it would complicate other things in our infrastructure.
ROOT##571.war
ROOT##572.war // hotfix of 5.7.1
ROOT##573.war // hotfix of 5.7.2
ROOT##600.war
ROOT##601.war // hotfix of 6.0.0
and two-step process of context version selection.
Step 1)
Belong the request to customer with version 5? -> pre-select ##571, ##572, ##573
Belong the request to customer with version 6? -> pre-select ##600, ##601
Done by my custom ContextVersionSelector interface implementation (which of coarse would check "customer" param in URI)
Step 2)
Use StandardContextVersionSelector on results from previous step (current behavior ... it would be used always as last applied selector)
If I understand the code right, all context selection magic is done in Mapper.java (which is now declared final) and it would have to be modified to support customizable version selection.
Is there a better way how to accomplish "slow pace" rollout of new version? (I mean with just Tomcat and nothing more)

Having multiple virtual hosts / tomcat instances is the usual way of
handling this but you have ruled that out.

It could be done fairly simply if you inserted a reverse proxy in front
of Tomcat but that breaks your 'just Tomcat' requirement.

Post by Tomáš Bleša
If not, do you consider my proposed Mapper imrovement interesting/useful? (I can try pull request)

This looks to be a fairly specific use case. Given that:
- the use case is specific
- the changes are likely to be quite invasive
- the changes would be to code that executes for every request

I suspect that there would be some resistance to these changes being
included in a standard Tomcat distribution.

What I think is much more likely is changes to visibility and/or
refactoring to make the context version selection pluggable so you (or
anyone else) can easily insert your own implementation. If you proposed
changes like that in a PR then I think they are much more likely to be
accepted.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-***@tomcat.apache.org
For additional commands, e-mail: users-***@tomcat.apache.org