You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Olle Hallin (JIRA)" <ji...@apache.org> on 2009/12/08 14:33:18 UTC
[jira] Created: (TAP5-945) Lock contention in PerthreadManagerImpl
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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Olle Hallin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787453#action_12787453 ]
Olle Hallin commented on TAP5-945:
----------------------------------
We tested with 1000 virtual users and 300 Tomcat threads.
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Joost Schouten (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787972#action_12787972 ]
Joost Schouten commented on TAP5-945:
-------------------------------------
that'll fix it then ;-) thx. Just wondered since the JDK bug was reported against 1.4.
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Olle Hallin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787969#action_12787969 ]
Olle Hallin commented on TAP5-945:
----------------------------------
T5 requires Java 1.5+
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787780#action_12787780 ]
Howard M. Lewis Ship commented on TAP5-945:
-------------------------------------------
The JDK bug was fixed in JDK6 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025230) but may still exist in JDK 1.5.
Best option would be to disable the synchronization unless JDK 1.5. That would be nice ... some free performance boost for using JDK 1.6.
ReentrantReadWriteLock would also work but there's a bit of overhead there.
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787780#action_12787780 ]
Howard M. Lewis Ship commented on TAP5-945:
-------------------------------------------
The JDK bug was fixed in JDK6 (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5025230) but may still exist in JDK 1.5.
Best option would be to disable the synchronization unless JDK 1.5. That would be nice ... some free performance boost for using JDK 1.6.
ReentrantReadWriteLock would also work but there's a bit of overhead there.
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787764#action_12787764 ]
Massimo Lusetti commented on TAP5-945:
--------------------------------------
I will definitely for the latter.
BTW Olle could you try to remove the sync blocks and see what happen?
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Olle Hallin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787969#action_12787969 ]
Olle Hallin commented on TAP5-945:
----------------------------------
T5 requires Java 1.5+
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Olle Hallin (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787453#action_12787453 ]
Olle Hallin commented on TAP5-945:
----------------------------------
We tested with 1000 virtual users and 300 Tomcat threads.
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Joost Schouten (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787966#action_12787966 ]
Joost Schouten commented on TAP5-945:
-------------------------------------
I'm not quite sure if it is possible to run Tapestry5 on java 1.4 and if anyone does, but looking at the current code the DummyLock will be used with anything but java 1.5. Is that what you want? Should it not be; use DummyLock when java version > 1.5?
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Closed: (TAP5-945) Unnecessary and severe lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-945.
-------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0.0
The synchronization logic is only present for JDK 1.5 now; for JDK 1.6 or above, no extra synchronization occurs.
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Closed: (TAP5-945) Unnecessary and severe lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship closed TAP5-945.
-------------------------------------
Resolution: Fixed
Fix Version/s: 5.2.0.0
The synchronization logic is only present for JDK 1.5 now; for JDK 1.6 or above, no extra synchronization occurs.
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Joost Schouten (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787972#action_12787972 ]
Joost Schouten commented on TAP5-945:
-------------------------------------
that'll fix it then ;-) thx. Just wondered since the JDK bug was reported against 1.4.
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Updated: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-945:
--------------------------------------
Summary: Unnecessary and severe lock contention in PerthreadManagerImpl (was: Lock contention in PerthreadManagerImpl)
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> 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.
[jira] Commented: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Joost Schouten (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787966#action_12787966 ]
Joost Schouten commented on TAP5-945:
-------------------------------------
I'm not quite sure if it is possible to run Tapestry5 on java 1.4 and if anyone does, but looking at the current code the DummyLock will be used with anything but java 1.5. Is that what you want? Should it not be; use DummyLock when java version > 1.5?
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> Priority: Minor
> Fix For: 5.2.0.0
>
>
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Massimo Lusetti (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12787764#action_12787764 ]
Massimo Lusetti commented on TAP5-945:
--------------------------------------
I will definitely for the latter.
BTW Olle could you try to remove the sync blocks and see what happen?
> 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.
[jira] Assigned: (TAP5-945) Lock contention in PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-945:
-----------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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.
[jira] Commented: (TAP5-945) Lock contention in
PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ 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.
[jira] Updated: (TAP5-945) Unnecessary and severe lock contention
in PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship updated TAP5-945:
--------------------------------------
Summary: Unnecessary and severe lock contention in PerthreadManagerImpl (was: Lock contention in PerthreadManagerImpl)
> Unnecessary and severe 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
> Assignee: Howard M. Lewis Ship
> 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.
[jira] Assigned: (TAP5-945) Lock contention in PerthreadManagerImpl
Posted by "Howard M. Lewis Ship (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/TAP5-945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Howard M. Lewis Ship reassigned TAP5-945:
-----------------------------------------
Assignee: Howard M. Lewis Ship
> 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
> Assignee: Howard M. Lewis Ship
> 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.