Hi!
We are load testing our new high volume site before soft launch, and we have
noticed that we have two sources of severe lock contention.
Of 300 threads, in average 165 are waiting for one of these two locks.
One is in ZipFile (caused by @IncudeJavaScriptLibrary("classpath:...")) and
the other is in
org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl
The ZipFile bottleneck is harmless, since we will use a CDN in production.
The second one is harder to work-around, since it is caused by
RequestGlobals.storeServletRequestResponse().
I have browsed PerthreadManagerImpl.java, and have found two cases where a
lock on "this" is requested.
In both cases the lock is requested before accessing a ThreadLocal
(ThreadLocal.get() and ThreadLocal.remove()).
Since ThreadLocal is thread-safe, external locking is uneeded.
Shall I file a JIRA issue, or have I missed something?
We use T5 5.1.0.5
Olle Hallin
Senior Java Developer and Architect
olle.hal...@crisp.se
www.crisp.se
http://www.linkedin.com/in/ollehallin
