[ 
https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13707431#comment-13707431
 ] 

Hadoop QA commented on HBASE-8877:
----------------------------------

{color:red}-1 overall{color}.  Here are the results of testing the latest 
attachment 
  
http://issues.apache.org/jira/secure/attachment/12592082/hbase-8807-v4-microbenchmark.txt
  against trunk revision .

    {color:green}+1 @author{color}.  The patch does not contain any @author 
tags.

    {color:red}-1 tests included{color}.  The patch doesn't appear to include 
any new or modified tests.
                        Please justify why no new tests are needed for this 
patch.
                        Also please list what manual steps were performed to 
verify this patch.

    {color:red}-1 patch{color}.  The patch command could not apply the patch.

Console output: 
https://builds.apache.org/job/PreCommit-HBASE-Build/6317//console

This message is automatically generated.
                
> Reentrant row locks
> -------------------
>
>                 Key: HBASE-8877
>                 URL: https://issues.apache.org/jira/browse/HBASE-8877
>             Project: HBase
>          Issue Type: Bug
>          Components: Coprocessors, regionserver
>            Reporter: Dave Latham
>            Assignee: Dave Latham
>             Fix For: 0.95.2
>
>         Attachments: hbase-8807-v4-microbenchmark.txt, HBASE-8877.patch, 
> HBASE-8877-v2.patch, HBASE-8877-v3.patch, HBASE-8877-v4.patch
>
>
> HBASE-8806 revealed performance problems with batch mutations failing to 
> reacquire the same row locks.  It looks like HBASE-8806 will use a less 
> intrusive change for 0.94 to have batch mutations track their own row locks 
> and not attempt to reacquire them.  Another approach will be to support 
> reentrant row locks directly.  This allows simplifying a great deal of 
> calling code to no longer track and pass around lock ids.
> One affect this change will have is changing the RegionObserver coprocessor's 
> methods preBatchMutate and postBatchMutate from taking a 
> {{MiniBatchOperationInProgress<Pair<Mutation, Integer>> miniBatchOp}} to 
> taking a {{MiniBatchOperationInProgress<Mutation> miniBatchOp}}.  I don't 
> believe CPs should be relying on these lock ids, but that's a potential 
> incompatibility.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to