[jira] [Commented] (HBASE-3587) Eliminate use of ReadWriteLock in RegionObserver coprocessor invocation

2011-04-07 Thread Hudson (JIRA)

[ 
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

2011-04-06 Thread Gary Helmling (JIRA)

[ 
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

2011-04-06 Thread stack (JIRA)

[ 
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

2011-03-01 Thread ryan rawson (JIRA)

[ 
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

2011-03-01 Thread stack (JIRA)

[ 
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

2011-03-01 Thread Mingjie Lai (JIRA)

[ 
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