DO NOT REPLY [Bug 43683] Accessing Servlet while Reloading context gives 404 error

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=43683





--- Comment #10 from Joe Kislo <jo...@k12s.phast.umass.edu>  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: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org