hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Elliott Clark (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-12588) Need to fail writes when row lock can't be acquired
Date Wed, 26 Nov 2014 22:28:12 GMT

    [ https://issues.apache.org/jira/browse/HBASE-12588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14226903#comment-14226903
] 

Elliott Clark commented on HBASE-12588:
---------------------------------------

bq.While current code still continues with writes.
Doesn't the break break you out of the loop? So lastIndexExclusive won't get updated and the
operations for where there was no lock aquired won't get applied. Then at the end of the function
the batch op will get the lastIndex updated.

> Need to fail writes when row lock can't be acquired
> ---------------------------------------------------
>
>                 Key: HBASE-12588
>                 URL: https://issues.apache.org/jira/browse/HBASE-12588
>             Project: HBase
>          Issue Type: Bug
>    Affects Versions: 0.98.8, 0.99.1
>            Reporter: Jeffrey Zhong
>            Assignee: Jeffrey Zhong
>         Attachments: HBASE-12588.patch
>
>
> Currently we don't fail write operations when can't acquiring row locks as shown below
in HRegion#doMiniBatchMutation. 
> {code}
> ...
>         RowLock rowLock = null;
>         try {
>           rowLock = getRowLock(mutation.getRow(), shouldBlock);
>         } catch (IOException ioe) {
>           LOG.warn("Failed getting lock in batch put, row="
>             + Bytes.toStringBinary(mutation.getRow()), ioe);
>         }
>         if (rowLock == null) {
>           // We failed to grab another lock
>           assert !shouldBlock : "Should never fail to get lock when blocking";
>           break; // stop acquiring more rows for this batch
>         } else {
>           acquiredRowLocks.add(rowLock);
>         }
> ...
> {code}
> We saw this issue when there is meta corruption problem and checkRow fails with error:
> {noformat}
> org.apache.hadoop.hbase.regionserver.WrongRegionException: Requested row out of range
for row lock on HRegion
> {noformat}
> While current code still continues with writes. In all cases, this is so dangerous because
row locks have to be acquired before update operations to guarantee row update atomicity.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message