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: [email protected]
ReportedBy: [email protected]
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: [email protected]
For additional commands, e-mail: [email protected]
