Hello Dan, > -----Ursprüngliche Nachricht----- > Von: Dan McLaughlin <d...@djabenterprises.com.INVALID> > Gesendet: Freitag, 16. Juni 2023 18:54 > An: Tomcat Users List <users@tomcat.apache.org> > Betreff: Words of Wisdom re: Context Versioning - Parallel Deployment > > 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? > > 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... > > 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. > > 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? > > Thanks! > > Dan >
Just some thoughts / ideas from my side: a) If you use any scheduler (e.g. quartz) you must use a DB based synchronization / clustering b) When using caches, they must be synchronized between the two apps c) Some frameworks have built-in caches which must be taken into account (e.g. eclipse link) d) Any shared resources should be checked whether parallel access might cause problems e) Opening listening ports might conflict I would like to try this feature in future. The above mentioned are some thoughts I made up to now. Greetings, Thomas --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
