[
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 this?
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
