|Summary:||Accessing Servlet while Reloading context gives 404 error|
|Product:||Tomcat 7||Reporter:||Ferenc Lutischan <yoursoft>|
|Component:||Catalina||Assignee:||Tomcat Developers Mailing List <dev>|
Description Ferenc Lutischan 2012-04-02 14:28:13 UTC
I think the following Tomcat 6 bug is reoccuring in Tomcat 7.0.26: https://issues.apache.org/bugzilla/show_bug.cgi?id=43683
Comment 1 Christopher Schultz 2012-04-03 20:24:28 UTC
Do you have any evidence to support a regression claim? Test case?
Comment 2 Ferenc Lutischan 2012-04-04 11:30:55 UTC
Created attachment 28542 [details] Test application Test application
Comment 3 Ferenc Lutischan 2012-04-04 11:40:27 UTC
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
Comment 4 Karl Penney 2012-04-07 00:59:09 UTC
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.
Comment 5 Christopher Schultz 2012-04-09 16:28:16 UTC
(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?
Comment 6 Karl Penney 2012-04-09 18:07:46 UTC
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?
Comment 7 Ferenc Lutischan 2012-04-10 18:12:03 UTC
> 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.
Comment 8 Mark Thomas 2012-05-07 14:15:21 UTC
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.
Comment 9 Mark Thomas 2012-05-08 19:08:09 UTC
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.