[jira] [Commented] (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016739#comment-13016739 ] Hudson commented on HBASE-3587: --- Integrated in HBase-TRUNK #1836 (See [https://hudson.apache.org/hudson/job/HBase-TRUNK/1836/]) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Assignee: Gary Helmling Fix For: 0.92.0 Attachments: HBASE-3587.patch Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016566#comment-13016566 ] Gary Helmling commented on HBASE-3587: -- Posted patch for review at: https://review.cloudera.org/r/1681/ Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Assignee: Gary Helmling Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13016607#comment-13016607 ] stack commented on HBASE-3587: -- +1 Nice one Gary. Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Assignee: Gary Helmling Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001166#comment-13001166 ] ryan rawson commented on HBASE-3587: +1 http://search-hadoop.com/m/jOovV1uAJBP data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001169#comment-13001169 ] stack commented on HBASE-3587: -- Thanks for filing this Gary. TRUNK seems broke. Its burning CPU like crazy. Perhaps it is this issue? Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation
[ https://issues.apache.org/jira/browse/HBASE-3587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13001173#comment-13001173 ] Mingjie Lai commented on HBASE-3587: stack. It's been in trunk for a while. Do you see the crazy-CPU-burning recently? From unit tests or at a cluster? Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation --- Key: HBASE-3587 URL: https://issues.apache.org/jira/browse/HBASE-3587 Project: HBase Issue Type: Improvement Components: coprocessors Reporter: Gary Helmling Follow-up to a discussion on the dev list: http://search-hadoop.com/m/jOovV1uAJBP The CoprocessorHost ReentrantReadWriteLock is imposing some overhead on data read/write operations, even when no coprocessors are loaded. Currently execution of RegionCoprocessorHost pre/postXXX() methods are guarded by acquiring the coprocessor read lock. This is used to prevent coprocessor registration from modifying the coprocessor collection while upcall hooks are in progress. On further discussion, and looking at the locking in HRegion, it should be sufficient to just use a CopyOnWriteArrayList for the coprocessor collection. We can then remove the coprocessor lock and eliminate the associated overhead without having to special case the no loaded coprocessors condition. -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
