[
https://issues.apache.org/jira/browse/HBASE-20574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16473208#comment-16473208
]
Ted Yu commented on HBASE-20574:
--------------------------------
By adding a DEBUG log before the return shown above, I saw the following in
unit test output:
{code}
hbase-server/target/surefire-reports/org.apache.hadoop.hbase.coprocessor.TestPassCustomCellViaRegionObserver-output.txt:2018-05-12
17:07:39,977 DEBUG [RpcServer.default.FPBQ.Fifo.handler=4,queue=0,port=35117]
regionserver.HRegion(5708): using passed
RowLockImpl{context=RowLockContext{row=ROW,
readWriteLock=java.util.concurrent.locks.ReentrantReadWriteLock@6ba035ba[Write
locks = 0, Read locks = 1], count=1,
threadName=RpcServer.default.FPBQ.Fifo.handler=4,queue=0,port=35117},
lock=java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock@5539c0cb[Read
locks = 1]}
{code}
Meaning prevRowLock would be passed back to caller in some cases.
> prevRowLock seems not working
> -----------------------------
>
> Key: HBASE-20574
> URL: https://issues.apache.org/jira/browse/HBASE-20574
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Reporter: Yi Zheng
> Priority: Major
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> In HRegion.java, getRowLockInternal using prevRowLock to check whether this
> lock is obtained before, but it may not work as imagine.
> Because this parameter passed as the last lock the thread obtained, and the
> code always be like this:
> {code:java}
> for (byte[] rows: rowsToLock) {
> rowLock = getRowLockInternal(row, prevRowLock);
> if (rowLock != prevRowLock){
> acquiredRowLocks.add(rowLock);
> prevRowLock = rowLock;
> }
> }{code}
> prevRowLock will never equal to the rowLockContext's lock in
> getRowLockInternal. I think this parameter is redundant.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
