DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43683>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43683 ------- Additional Comments From [EMAIL PROTECTED] 2007-10-23 09:48 ------- This is how I envision the reload function working: 1) The servlet is happily handling GET/POST requests 2) reload is requested from the manager servlet 3) All new requests should be put into a queue, and wait to be serviced 4) If there are any 'currently active requests', tomcat should wait up to StandardContext.unloadDelay seconds waiting for these requests to finish 5) Any requests that finish should be sent to the browser and finished up 6) When unloadDelay has been exceeded, or all currently active requests are completed, destroy() should be called on the servlet 7) Wait until destroy() has finished 8) Clean up the context, and switch the classloader to the new classloader 9) If there are any requests in the queue, start the servlet, call init(ServletConfig) on the servlet 10) wait for init(ServletConfig) to complete 11) All new requests should nolonger be put into queue, and should be serviced by the servlet 12) All requests which are in queue, should now be released and processed against the new servlet Looking at the code in StandardContext, I can see this is probably what it supposed to happen (it tries to pause incoming requests)... it just doesn't quite work. What we see is that if a request comes in while the servlet is being destroyed, it will get a 404 from the servlet when the destroy() method completes (EG: not right away!). I looked at the code very reasonably thoroughly in tomcat 5.5 (more thoroughly than I am looking at it right now) and I seem to remember discovering that it was the start() context method that was actually destroying the waiting request. But I can't vouch for that, it was probably a year ago :) It is worth noting that if you send in a SECOND request while the servlet is being destroyed, that request *IS* handled properly... However... you can't send that second request in TOO quickly after the first. If they all come in at the same time (see the apache bench testcase), they will *all* fail. However even if you're doing it reasonably quickly from firefox, the second request will come through correctly. I should also note that we had a patch for tomcat 4.1 which made the reload() function work the way described above (it was a rather minor change), however the patch is useless against tomcat 5 and greater, since the start/stop code has been rewritten. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
