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