Author: kkolinko
Date: Mon Nov 2 10:40:52 2009
New Revision: 831854
URL: http://svn.apache.org/viewvc?rev=831854&view=rev
Log:
shorten comment, add a proposal that implements it
Modified:
tomcat/tc6.0.x/trunk/STATUS.txt
Modified: tomcat/tc6.0.x/trunk/STATUS.txt
URL:
http://svn.apache.org/viewvc/tomcat/tc6.0.x/trunk/STATUS.txt?rev=831854&r1=831853&r2=831854&view=diff
==============================================================================
--- tomcat/tc6.0.x/trunk/STATUS.txt (original)
+++ tomcat/tc6.0.x/trunk/STATUS.txt Mon Nov 2 10:40:52 2009
@@ -37,32 +37,13 @@
+1: markt, funkman, kkolinko
0: remm (looks risky, very minor problem), fhanik - minor problem, jim
-1:
- kkolinko: (Notes:
- 1. This does not affect configurations where Jasper is run with
- development=false. In those configurations JSP removal is not detected
- at all.
-
-
- 2. I think that, strictly speaking, JspCompilationContext#removed field
- has to be either volatile or AtomicInteger, or there must be
- synch(JspServletWrapper) when accessing it:
-
- JspCompilationContext#incrementRemoved() is always called from inside a
- synchronized(JspServletWrapper) block, but
- JspCompilationContext#isRemoved() is e.g. called in
- JspServletWrapper#service() which is not synchoronized.
-
- Of course, that happens only when development=true. Otherwise that
- field is always 0. Thus I am hesitant to adding volatile to it to not
- affect productive configurations. Maybe double-lock pattern is better
- (like one in JspServletWrapper#getServlet()).
-
- This issue with JspCompilationContext#removed field is not a blocker
- for this patch, because it exists independently of it. And I think it
- would be hardly noticeable, as it won't be observed if there were any
- (unrelated) synchs earlier in the same Thread, and e.g. with
- development=true mode there is a syncronized(this) block below in
- JspServletWrapper#service().
+
+ kkolinko: (
+ - This issue does occur only when development = true.
+ When development is false JSP removal is not detected at all.
+
+ - I think that, strictly speaking, JspCompilationContext#removed field
+ has to be volatile. I am proposing the change below (backport of r.831850)
)
* Backport cleanup of semantics of thisAccessedTime and
@@ -432,3 +413,8 @@
http://people.apache.org/~kkolinko/patches/2009-11-02_ApplicationContextFacade.patch
+1: kkolinko
-1:
+
+* Mark JspCompilationContext#removed as volatile
+ http://svn.apache.org/viewvc?rev=831850&view=rev
+ +1: kkolinko
+ -1:
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
