[
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-refCounts-v5.patch
Attaching HBASE-8877-refCounts-v5.patch
This one's for all the marbles.
- Reformatted the too-long line (thanks Hadoop QA)
- improved a log message and an exception message
- reduced scope of RowLockContext methods from public to package
Here are the changes from HBASE-8877-refCounts-v4.patch to
HBASE-8877-refCounts-v5.patch
{noformat}
476,477c476,477
< + public RowLock getRowLock(final byte[] row, boolean waitForLock)
< throws IOException {
---
> - throws IOException {
> + public RowLock getRowLock(byte[] row, boolean waitForLock) throws
> IOException {
499c499
< + // Row is already locked by some other thread
---
> + // Row is already locked by some other thread, give up or wait for
> it
505a506,507
> - throw new IOException("Timed out on getting lock for row="
> - + Bytes.toStringBinary(row));
> + throw new IOException("Timed out waiting for lock for row: " +
> rowKey);
510c511,516
> - LOG.warn("internalObtainRowLock interrupted for row=" +
> Bytes.toStringBinary(row));
> + LOG.warn("Thread interrupted waiting for lock on row: " +
> rowKey);
1144c1150
< + public RowLockContext(HashedBytes row) {
---
> + RowLockContext(HashedBytes row) {
1149c1155
< + public boolean ownedByCurrentThread() {
---
> + boolean ownedByCurrentThread() {
1153c1159
< + public RowLock newLock() {
---
> + RowLock newLock() {
1168c1174,1175
< + throw new RuntimeException("Internal row lock state inconsistent,
should not happen, row: " + row);
---
> + throw new RuntimeException(
> + "Internal row lock state inconsistent, should not happen, row:
> " + row);
{noformat}
> 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-0.94-v2.patch, HBASE-8877.patch,
> hbase-8877-refCounts-microbenchmarks.txt, HBASE-8877-refCounts.patch,
> HBASE-8877-refCounts-v2.patch, HBASE-8877-refCounts-v3.patch,
> HBASE-8877-refCounts-v4.patch, HBASE-8877-refCounts-v5.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-8877-v7.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
