I think the following Tomcat 6 bug is reoccuring in Tomcat 7.0.26: https://issues.apache.org/bugzilla/show_bug.cgi?id=43683
Do you have any evidence to support a regression claim? Test case?
Created attachment 28542 [details] Test application Test application
Test case: - Unzip the downloaded Tomcat 7.0.26 from tomcat.apache.org site - Edit the unzipped dir/conf/tomcat-users.xml. Add the following line: <user password="ide" roles="standard,manager-gui,admin" username="ide"/> - Unzip the attached "Test application" into the unzipped dir/webapps - start tomcat - open http://localhost:8080/ServletRestartTest/ServletRestartTest - open the manager application (http://localhost:8080/manager/html) with ide/ide - reload the ServletRestartTest application from manager application - while it reloading try to reload the http://localhost:8080/ServletRestartTest/ServletRestartTest url. - You will get a 404 error page
The problem seems to be that the wrappers (servlets) are unregistered from the context as part of the stop process. If a request comes in before the context is started again, then no wrapper gets mapped to the request and StandardContextValve returns SC_NOT_FOUND.
(In reply to comment #4) > The problem seems to be that the wrappers (servlets) are unregistered from the > context as part of the stop process. If a request comes in before the context > is started again, then no wrapper gets mapped to the request and > StandardContextValve returns SC_NOT_FOUND. This isn't a bug: it's how Tomcat works. Why would your undeployed context still be able to successfully serve requests?
It shouldn't reject requests while the context is being reloaded. The StandardContextValve waits for the reload to complete, but by that point it can be too late since the request wrapper might not have gotten set. Maybe Tomcat should not unregister the wrappers when a context is reloaded?
> This isn't a bug: it's how Tomcat works. Why would your undeployed context > still be able to successfully serve requests? Tomcat 6 doesn't send 404 when context is reloading.
I can recreate this with the provided test case. The 404 response is not the expected behaviour. Tomcat should pause the request until the application finishes reloading and then server.
Thanks for the test case. This has been fixed in trunk and 7.0.x and will be included in 7.0.28 onwards. I also took the opportunity to improve the handling when a watched resource (such as web.xml) changes. This is now handled with a reload (so no 404s) rather than stop followed by a start.