[
https://issues.apache.org/jira/browse/HBASE-18144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16051721#comment-16051721
]
Yu Li commented on HBASE-18144:
-------------------------------
Nice debugging! [~allan163]
While in branch-1.1, I could see below codes in {{HRegion#getRowLockInternal}}
{code}
// Row is already locked by some other thread, give up or wait for it
if (!existingContext.latch.await(this.rowLockWaitDuration,
TimeUnit.MILLISECONDS)) {
if(traceScope != null) {
traceScope.getSpan().addTimelineAnnotation("Failed to get row
lock");
}
throw new IOException("Timed out waiting for lock for row: " +
rowKey);
}
{code}
So I think it's still waiting for the row lock, right? I guess the difference
mainly lies in the if-else logic inside getRowLockInternal method that we don't
always wait, but haven't dig deep into it. Maybe a little bit more
investigation required about why branch-1.1 don't have HBASE-17924 problem?
Thanks.
> Forward-port the old exclusive row lock; there are scenarios where it
> performs better
> -------------------------------------------------------------------------------------
>
> Key: HBASE-18144
> URL: https://issues.apache.org/jira/browse/HBASE-18144
> Project: HBase
> Issue Type: Bug
> Components: Increment
> Affects Versions: 1.2.5
> Reporter: stack
> Assignee: stack
> Fix For: 2.0.0, 1.3.2, 1.2.7
>
> Attachments: DisorderedBatchAndIncrementUT.patch,
> HBASE-18144.master.001.patch
>
>
> Description to follow.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
