https://issues.apache.org/bugzilla/show_bug.cgi?id=49986
Tim Whittington <t...@apache.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|Jasper |Jasper
Version|6.0.29 |trunk
Product|Tomcat 6 |Tomcat 7
Target Milestone|default |---
--- Comment #3 from Tim Whittington <t...@apache.org> 2010-09-30 01:27:22 EDT
---
This is actually one of the rare cases that DCL is a decent solution, but the
current implementation is broken.
The fix for getServlet (now Java 5 has come along) is a volatile reload flag.
This forces an in order write of the new servlet object and the 'theServlet'
reference (as long as the write to reload is the last step in the update), as
well as forcing a read barrier (and thus a consistent read of 'theServlet' and
the new servlet object) for any thread entering getServlet after a reload is
done.
setServletClassLastModifiedTime can be fixed by making
servletClassLastModifiedTime volatile (again since Java 5).
(This could be done with an AtomicLong and a busy loop compareAndSet, but the
volatile DCL is a more minor change and the performance diff is probably
negligible).
e.g.:
final AtomicLong lastModifiedTime = new AtomicLong();
while (true) {
long current = lastModifiedTime.get();
if (current < lastModified) {
if (lastModifiedTime.compareAndSet(current, lastModified)) {
reload = true;
break;
}
} else {
break;
}
}
I'll move this to Tomcat 7 and look at a fix there - depending on the
confidence we have it may find it's way back to 6.x (although I've been running
Tomcat in production for a decade and have never seen a practical failure from
this).
--
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
