[
https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787747#action_12787747
]
Howard M. Lewis Ship commented on TAP5-945:
-------------------------------------------
As I mentioned on the mailing list, this addresses a bug that may still be
present in Sun JDK 1.5, that ThreadLocal is not fully thread safe (!) in some
situations ... the kind of situations that Tapestry hits.
This could be recoded in a couple of ways. We could use a configuration symbol
or JVM system property to enable/disable the synchronization. We could add a
test for JDK 1.6 to disable the synchronization. We could use a
ReentrantReadWriteLock to allow shared readers (the common case).
> Lock contention in PerthreadManagerImpl
> ---------------------------------------
>
> Key: TAP5-945
> URL: https://issues.apache.org/jira/browse/TAP5-945
> Project: Tapestry 5
> Issue Type: Bug
> Components: tapestry-core
> Affects Versions: 5.1.0.5
> Reporter: Olle Hallin
> Priority: Minor
>
> When load testing our new high-volume site before soft launch, we found that
> we have severe lock contention in
> org.apache.tapestry5.ioc.internal.services.PerthreadManagerImpl.
> It synchronizes on "this" before invoking ThreadLocal.get() and
> ThreadLocal.remove(), which I believe is unnecessary.
> During our tests, approximately 35% of all Tomcat threads were waiting for
> this lock in any of 10 thread dumps taken 15 seconds apart.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
