https://issues.apache.org/bugzilla/show_bug.cgi?id=48170
--- Comment #2 from Sebb <s...@apache.org> 2009-11-11 03:13:35 UTC --- (In reply to comment #1) > (In reply to comment #0) > > 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. > > In which case, the setter should be package-protected? Sorry, that's nonsense - different packages. > > 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. > > Might be worth trying synch. on a private static lock Object instead of an > inner class? That might perhaps help. > If the JspFactory class can be loaded after the JspRuntimeContext class, then > JspRuntimeContext could store the factory as a static final field which could > be accessed by JspFactory on startup. > > Or indeed, do away with setDefaultFactory() and have getDefaultFactory() > return > the static final value from JspRuntimeContext? That's nonsense too. -- 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
