hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Enis Soztutar (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-14689) Addendum and unit test for HBASE-13471
Date Wed, 18 Nov 2015 22:02:11 GMT

     [ 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)

Mime
View raw message