hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Latham (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-8877) Reentrant row locks
Date Sat, 13 Jul 2013 17:05:49 GMT

     [ https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Dave Latham updated HBASE-8877:

    Attachment: HBASE-8877-v6.patch

Last patch failed on TestHeapSize.  This surprised me since it had passed for me locally.
 Turns out locally I was on a 64-bit VM and Jenkins ran it out a 32-bit.  It also turns out
the current trunk had the FIXED_OVERHEAD off by +1 long, -1 reference and -2 booleans which
just happened to pass the tests due to alignment but after this change began to fail.  Digging
further it's obvious the DEEP_OVERHEAD is missing many fields as is the heapSize() method.
 Looks like we may not be even trying any more.  Has there already been any discussion about

Attaching v6 patch.  In this patch I've corrected FIXED_OVERHEAD which gets the test passing.
 I also added a couple missing AtomicIntegers to DEEP_OVERHEAD as well as a comment specifying
all the other missing things which I think is too great a scope for me to try to fix in this
patch, but at least serves as a warning to others. 
> 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-8877-0.94-microbenchmark.txt, HBASE-8877-0.94.patch, HBASE-8877.patch,
HBASE-8877-v2.patch, HBASE-8877-v3.patch, hbase-8877-v4-microbenchmark.txt, HBASE-8877-v4.patch,
HBASE-8877-v5.patch, HBASE-8877-v6.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

View raw message