Dan,
On 6/20/23 18:03, Christopher Schultz wrote:
Dan,
On 6/16/23 12:54, Dan McLaughlin wrote:
Does anyone have any advice on implementing Context Versioning (parallel
deployment) in Tomcat? It seems to have been a feature for quite some
time.
Is it stable? What are the typical issues people run into? JMX issues?
Classloader issues?
It should definitely be stable. No issues with JMX or ClassLoading, but
it may depend upon how your environment uses those things.
I've tried to do a parallel deployment with our applications as they
exist
today, and I can already see a few problems we'd have to address.
1) We have a concept of a workdir where we will extract
configuration-related properties files, XML, etc... on initial start-up;
the workdir also contains working files related to things like XA
transaction logs and application-specific logging. We'd probably need to
append the context version to our workdir path so that each version can
have separate application logs, configuration settings, etc...
You may want to use the servlet-spec-defined temporary directory instead
of just setting one and using it -- possibly external to your
application. If you always want to set things up on startup, then the
container will give you an application-specific (and, in fact,
application-version-specific) work directory in the context/application
scope attribute called "javax.servlet.context.tempdir". The object under
that key is a java.io.File and should point to a directory you can use
while the application is deployed. There are no guarantees about
information persisting across application deployments, restarts, etc.
2) We use JMX MBeans throughout our apps to allow real-time configuration
of our applications. Since our apps weren't originally developed with
parallel deployment in mind, so a parallel deployment results in two app
versions trying to use the same JMX MBeans. I can see in our app logs
when
I try to deploy two versions, the second version will
either throw an exception and fail to start because the MBean exists,
or it
will try to destroy and recreate the MBean--which could cause issues
if it
changes a setting that the first version of the app depended on. I assume
we will need to fix all our code to somehow version the MBeans so there
aren't conflicts.
This is one of those areas where "how your environment uses things"
needs to be taken into account. If you inject things into the JMX tree,
then you'll need to take responsibility for what happens with multiple
parallel versions.
I briefly looked at the documentation for parallel deployment
(https://tomcat.apache.org/tomcat-9.0-doc/config/context.html#Parallel_deployment) and I do not see any references to how an application might be able to detect its own "version" but I'm almost certain such a thing exists. If not, it really should exists if only for this kind of thing you describe here.
I found it: there is a context/application attribute key
"org.apache.catalina.webappVersion" which contains the String value of
the webapp version. Mine is "" (or null?) because I don't have a version
string after my webapp name, but I suspect it would be something like
"01" if you deployed "myapp##01.war".
You could use that version string to ensure that your JMX registrations
did not conflict with each other. You'd *also* probably need to publish
the current list of deployed versions via JMX so that clients can detect
which version(s) are available to sample.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
