[
https://issues.apache.org/jira/browse/HBASE-8877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dave Latham updated HBASE-8877:
-------------------------------
Attachment: hbase-8807-v4-microbenchmark.txt
HBASE-8877-v4.patch
[~churromorales] ran the patch v3 through his microbenchmark on mini batch
puts. It revealed an issue in the patch that the list of locks from the same
thread held duplicates resulting in erroneous errors being logged. Here's a v4
patch fixing that issue. Here are also results for the microbenchmark on this
patch that show it as fast or faster than the existing trunk.
If this looks good, It think it's ready for commit to trunk and 0.96.
Should also have a patch soon for 0.94 that is similar to Anoop's patch on
HBASE-8806 but only uses reentrancy for doMiniBatchMutation and
mutateRowsWithLocks to avoid problems with client side row locks. Verifying
tests and perf for that one.
> 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
