| Summary: | Child name [/app1] is not unique after upgrading 9.0.44 | ||
|---|---|---|---|
| Product: | Tomcat 9 | Reporter: | abhishekm |
| Component: | Manager | Assignee: | Tomcat Developers Mailing List <dev> |
| Status: | RESOLVED FIXED | ||
| Severity: | critical | ||
| Priority: | P2 | ||
| Version: | 9.0.44 | ||
| Target Milestone: | ----- | ||
| Hardware: | Other | ||
| OS: | Linux | ||
| Attachments: | server.xml | ||
|
Description
abhishekm
2021-04-19 21:43:21 UTC
Thanks for the report. It appears that both the deploy thread and the background processing thread are trying to deploy the updated WAR file. There is code that is meant to prevent that. I've found a bug in that code that allows me to recreate the stacktrace you reported. I am working on a fix. To be sure I have found the same error you are seeing, can you clarify what you mean by "preventing app1 to start normally"? In my testing when the two threads attempt to start the updated application, one of those threads succeeds and one fails. The app does start. To put it another way, the bug just causes an ugly stack trace in the logs, it doesn't prevent the deployment from completing nor does it break the application. Are you seeing the same? A potential workaround would be to disable automatic deployment (autoDeploy="false" on the Host). If you are doing all your deployments via the Manager then you might want to do this anyway for the security benefits (an arbitrary file upload vulnerability can't be leveraged into RCE). Fixed in: - 10.0.x for 10.0.6 onwards - 9.0.x for 9.0.46 onwards - 8.5.x for 8.5.66 onwards Feel free to re-open if the issue you found isn't the one I've just fixed. (In reply to Mark Thomas from comment #1) > Thanks for the report. > > It appears that both the deploy thread and the background processing thread > are trying to deploy the updated WAR file. There is code that is meant to > prevent that. I've found a bug in that code that allows me to recreate the > stacktrace you reported. I am working on a fix. > > To be sure I have found the same error you are seeing, can you clarify what > you mean by "preventing app1 to start normally"? > > In my testing when the two threads attempt to start the updated application, > one of those threads succeeds and one fails. The app does start. To put it > another way, the bug just causes an ugly stack trace in the logs, it doesn't > prevent the deployment from completing nor does it break the application. > Are you seeing the same? > > A potential workaround would be to disable automatic deployment > (autoDeploy="false" on the Host). If you are doing all your deployments via > the Manager then you might want to do this anyway for the security benefits > (an arbitrary file upload vulnerability can't be leveraged into RCE). When we saw "Child name [/app1] is not unique" and visited `app1` web page, we saw following error. It seems one of the war attempts was successful but the application did not start normally. Our context.xml defines database resources. javax.naming.NameNotFoundException: Name [comp/env] is not bound in this Context. Unable to find [comp]. org.apache.naming.NamingContext.lookup(NamingContext.java:833) org.apache.naming.NamingContext.lookup(NamingContext.java:174) org.apache.naming.SelectorContext.lookup(SelectorContext.java:163) javax.naming.InitialContext.lookup(InitialContext.java:417) |