https://issues.apache.org/bugzilla/show_bug.cgi?id=43683
--- Comment #10 from Joe Kislo <[EMAIL PROTECTED]> 2008-06-05 19:46:01 PST --- Well thanks for the compliment on the test cases... These issues are very important to us, so I'm *extremely* grateful you're spending time looking into them. But I'm sorry to report that my test case for this next one isn't as good :) So first, your fix with the classloader issues seems to have fixed up that problem. However, if I use the 2nd testcase, and do: ab -c 10 -n 60 http://localhost:8080/ServletRestartTest2/ServletRestartTest then reload the context: http://localhost:8080/ServletRestartTest2/ServletRestartTest I am still getting some non 200 requests: Complete requests: 60 Failed requests: 11 (Connect: 0, Length: 11, Exceptions: 0) Write errors: 0 Non-2xx responses: 11 I swear I didn't this before... So maybe I'm crazy... But maybe I was distracted last time by trying to track down the classloader testcase. If I try to do the tests from my browser... they *usually* work just fine. But sometimes, I'll get the 404 in my browser too. I would just say it's a race condition as to when I reload the context, but can't quite put my finger on it. It seems like once it gets one 404... every time I try it after that (until I restart tomcat) it'll get the 404 on reload. *sigh* Sorry I can't be more helpful. Can you tell me if you are still seeing non-200s with the apache bench test? It seems like maybe you fixed one path where you can get a 404, but maybe there's another. It looks like requests that come in right after the destroy finishes, but before the init starts that are getting the 404s now. So I did find a *second* issue, which is also intermittent, and may have been introduced by your first fix (although I don't know). I've spent the past two days (well, a couple hours yesterday and a few hours today) trying to get a narrow testcase for you. I've got one, and I'll attach it as ServletRestartTest3. In your browser, you need to open Three tabs 1:http://localhost:8080/manager/reload?path=/ServletRestartTest3 2:http://localhost:8080/ServletRestartTest3/ServletRestartTest 3:http://localhost:8080/ServletRestartTest3/ServletRestartTest You need to start tomcat, then reload tab 2, then 1, then 3 This is what happens (sometimes!) the servlet will init() then the servlet will destroy() but while the destroy is running, it will service the request for tab 2 on the same servlet the destroy() will finish the servlet will init() the servlet will service tab 3. Unfortunately, what it's doing is serving a request (tab #2) *while* it's in the middle of destroying the context. Bad bad bad :( In the testcase I have rigged up it will cause a nullpointer exception in tab #2 when that happens: java.lang.NullPointerException ServletRestartTest.doGet(ServletRestartTest.java:43) javax.servlet.http.HttpServlet.service(HttpServlet.java:617) javax.servlet.http.HttpServlet.service(HttpServlet.java:717) You'll see this on your tomcat console: init starting [GC [DefNew: 960K->64K(960K), 0.0029550 secs] 4176K->3426K(5056K), 0.0029980 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] Jun 5, 2008 10:13:07 PM org.apache.catalina.core.StandardContext reload INFO: Reloading this Context has started init completed destroy starting starting servicing destroy completed [GC [DefNew: 960K->64K(960K), 0.0034250 secs] 4322K->3539K(5056K), 0.0034690 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] [GC [DefNew: 960K->64K(960K), 0.0019920 secs] 4435K->3623K(5056K), 0.0020690 secs] [Times: user=0.01 sys=0.00, real=0.00 secs] init starting init completed starting servicing servicing completed If you can't get it to happen first try, reload tab #1, which will shutdown the context... Then do tab #2, #1, #3. It may take you a few times to get it to happen. It's intermittent :( You'll see that Testcase #3 has a very tight loop at the init(). I tried a sleep(5000), and it was *significantly* more difficult to get the problem to happen. With the 5 second tight loop, it's much easier (although still not consistent). Let me know if there's anything I can do to help -- Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]