tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Howard M. Lewis Ship (JIRA)" <j...@apache.org>
Subject [jira] Commented: (TAP5-945) Lock contention in PerthreadManagerImpl
Date Tue, 08 Dec 2009 21:22:18 GMT

    [ 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.


Mime
View raw message