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.
3) Do third-party dependencies that use JMX pose any issues? We use jgroups and log4j2. Both create their own mbeans, but it seems we have control over the names they use. Do you know if there are any other issues we need to consider? Words of wisdom?
I don't use parallel deployment myself so I don't have much in the way of wisdom for you. But users like you who are using features like this in non-trivial environments are very valuable to us. We can flesh-out features that work in unit tests and simple environments but have these rough edges.
Please continue to engage this community on these issues so we can improve Tomcat.
Thanks, -chris --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
