On 06/01/2021 21:48, Manuel Dominguez Sarmiento wrote: > Hi, our system consists on about 80+ webapps on different servers. > Multiple webapps are deployed per Tomcat server remotely using the > manager and host-manager webapps. > > This has been working fine for years, however some servers now have 5+ > webapps and they are taking a long time to start. We invoke the deploy > command on the manager webapp in parallel for each webapp, in order to > attempt a reduction in total server startup time. However the speedup is > very modest. The servers have powerful Xeon multi-core servers so a > parallel speedup should be possible. > > Looking at the source code for > org.apache.catalina.manager.ManagerServlet we see that the following > method is synchronized which would explain the behaviour we are seeing: > protected synchronized void deploy > (PrintWriter writer, String config, ContextName cn, > String tag, boolean update, HttpServletRequest request, > StringManager smClient) { > > Is there any real reason why this needs to be synchronized? Tomcat can > deploy webapps in parallel when backgroundProcessorDelay is set to a > positive number, but this is not useful when remotely deploying webapps > using the manager webapp. > > Any ideas? Thanks
Some svn archaeology uncovered this commit comment: "Known issue: locking occurs on an uploaded WAR, for reasons which elude me right now." The method level sync looks like an attempt to ensure that there aren't parallel attempts to deploy a web application to the same path. I can't think of any other reason. But locking on, essentially, the virtual host, seems overly broad. A lock on the deployment path would be sufficient. There are also calls to isServiced(), addServiced() and removeServiced() which look to be trying to do the same thing which have their own issues (not atomic, uses a List rather than a Set). We do need to ensure that we don't get parallel attempts to service the same web application. There is scope for all sorts of bad things to happen if that is possible. Overall, I think this can be fixed but it looks like some API changes are going to be required which makes things a little more complicated. It would be worth you opening a Bugzilla issue for this to make sure it doesn't get forgotten about. The issues with the unsynchronized deployment methods are sufficient - in my view - to class this as a bug rather than an enhancement. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org