https://issues.apache.org/bugzilla/show_bug.cgi?id=50885
Summary: JspServletWrapper can call destroy() on a JSP page that is still in service() Product: Tomcat 7 Version: trunk Platform: PC OS/Version: Windows XP Status: NEW Severity: minor Priority: P2 Component: Jasper AssignedTo: dev@tomcat.apache.org ReportedBy: knst.koli...@gmail.com I noticed this while reviewing r1078409 which was a fix inspired by this discussion, "atomicity violation in the JspServletWrapper class" @dev list http://tomcat.markmail.org/thread/htekwb5aq4urrf76 The Ch.2.3.4 of Servlet 3.0 says that before destroy() method of a servlet is called all the threads must finish service() (or some timeout to pass). What I do not like is that 1) JspServletWrapper.getServlet() calls JspServletWrapper.destroy() while there is no guarantee that the servlet is not still in service. 2) we are able to call service() on a servlet after its destroy() has been called. This issue existed before r1078409, but now "2)" is slightly more noticeable, because we remember the value returned by getServlet() in a local variable. Reverting r1078409 is no good, because it just adds a risk of accessing an instance of servlet before it is properly initialized (because reading of theServlet field were not protected by a sync), but does not solve this issue. I think this is hard to observe, though, because 1) The servlet is not just any servlet, but a JSP page. The jspDestroy() method in a JSP page is usually a NOOP. The _jspDestroy() method though does some work (see Generator.generateDestroy()): releases tag handler pools. 2) The reloading occurs only when running with development=true in JspServlet configuration. Those running with development=false are unaffected. -------------------------------------- There are also calls to JspServletWrapper.destroy() from JSP unloading feature (new in TC7). I wonder whether those play fine. -- 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org