[
https://issues.apache.org/jira/browse/HBASE-14689?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Enis Soztutar updated HBASE-14689:
----------------------------------
Attachment: hbase-14689-after-revert.patch
It seems that the (now-reverted) v1 patch will only cause a problem in branches
where HBASE-12751 is not committed. HBASE-12751 makes it so that row locks are
shared for write-only transactions (doBatchMiniMutation()) and thus lock order
is not important and we can do blocking acquire while holding other row locks
in the same batch. Read-write transactions (append, incr, mutateRowsWithLocks()
either does not happen in batch, or orders the row locks, so there is no dead
lock there.
For 1.1 and below, we should keep the try-acquire of row-locks in the batch
processing so that no deadlock can happen. We can commit the attached patch to
all branches I think, now that the scope is reduced (just removes an assert
since row lock timeout is a valid case).
> Addendum and unit test for HBASE-13471
> --------------------------------------
>
> Key: HBASE-14689
> URL: https://issues.apache.org/jira/browse/HBASE-14689
> Project: HBase
> Issue Type: Bug
> Reporter: Enis Soztutar
> Assignee: Enis Soztutar
> Fix For: 2.0.0, 1.2.0, 1.3.0, 1.0.3, 1.1.3, 0.98.16
>
> Attachments: hbase-14689-after-revert.patch,
> hbase-14689_v1-branch-1.1.patch, hbase-14689_v1-branch-1.1.patch,
> hbase-14689_v1.patch
>
>
> One of our customers ran into HBASE-13471, which resulted in all the handlers
> getting blocked and various other issues. While backporting the issue, I
> noticed that there is one more case where we might go into infinite loop. In
> case a row lock cannot be acquired (due to a previous leak for example which
> we have seen in Phoenix before) this will cause similar infinite loop.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
