https://issues.apache.org/bugzilla/show_bug.cgi?id=48170
Summary: Unnecessary synchronization by
JspFactory.getDefaultFactory contributes to stability
problems
Product: Tomcat 6
Version: 6.0.16
Platform: Sun
OS/Version: Solaris
Status: NEW
Severity: major
Priority: P2
Component: Catalina
AssignedTo: dev@tomcat.apache.org
ReportedBy: earl.no...@nfl.com
I have a soak test at constant load that is initially stable. Within the hour,
an ever increasing number of blocked threads develops. The vast majority of
threads are in JSP rendering, blocked on JspFactory.getDefaultFactory().
The server eventually crashes.
We are running Java 6.
Upon code inspection, there appears to be no real reason for synchronizing the
getDefaultFactory() and setDefaultFactory() as the setter is called only once
upon startup when the sub-class loads.
Patching the jar, I tried three other experiments:
1) Removing the synchronized keyword entirely.
2) Locking on an inner static class instead of the JspFactory.class.
3) Using volatile for the static member variable.
Both experiments #1 and #3 showed vastly better stability. I was able to
double the throughput of the server without seeing increasing number of blocked
threads.
Experiment #2 yielded the same behavior as the original code. Thus, no other
code
is synchronizing on JspFactory.class. Rather, there seem to be some sort of
contention in the java.lang.Class monitor.
Using volatile would preserve the multi-threading semantics while avoiding
contributing to the instability issue.
--
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
