On 21.10.2010 20:52, Mark Thomas wrote:
All,
As most of you are probably aware I work for SpringSource and
SpringSource has an application server product - tc Server - that is
heavily based on Apache Tomcat. When talking to prospective clients
about tc Server, one of the things we often hear is "WebSphere/WebLogic
has XYZ feature - does tc Server?" and one of those features is parallel
deployment.
Parallel deployment is essentially having two (or more) versions of the
same application deployed side-by-side. Users with a session in an older
version, will continue to use that older version until the session
expires. Users without a session, or whose session expires, will use the
latest version. Once there are no sessions using the older version it is
undeployed. All versions of the application have the same context path
so the transition is seamless to the users.
Having looked at some implementation options, it quickly became apparent
that Tomcat was the right place to implement this rather than as an
'add-on' in tc Server. I have managed to convince senior management
that contributing an implementation of parallel deployment to the ASF is
the way to go. I currently have a hacked together implementation [1]
that works but is very ugly in places under the covers and there is
still some significant work to go before it is robust enough to be put
into trunk (it changes the mapper and that is an area I think we need to
be very careful).
A lot of the patch is dealing with the issues around the fact that we
currently treat Context.getPath() and Context.getName() as the same
thing but with parallel deployment these need to be treated differently.
My proposal is therefore:
- start committing some of the getPath() / getName() clean-up to trunk
along with some of the other hooks - like adding a version attribute to
Context that should be minimal risk
- continue testing the current patch (e.g. with clustering) and modify
as required
- discuss the implementation details (like the file naming convention
used) on the dev list
- decide once we can see the patch without the clean-up if it is safe
for 7.0.x or needs to be held back for 7.1.x
Depending on how big this patch ends up looking then creating a branch
for this work may make sense. I'd like to hold off creating a branch for
a few days until the clean-up changes have been made to trunk so the
branch can focus on the diffs required for the new feature.
As always, any and all feedback welcome.
Great initiative, good plan.
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
