You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hbase.apache.org by "Lars Hofhansl (JIRA)" <ji...@apache.org> on 2014/08/01 01:57:38 UTC
[jira] [Resolved] (HBASE-11623) mutateRowsWithLocks might require
updatesLock.readLock with waitTime=0
[ https://issues.apache.org/jira/browse/HBASE-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Lars Hofhansl resolved HBASE-11623.
-----------------------------------
Resolution: Fixed
Hadoop Flags: Reviewed
Committed to everywhere (except 0.96)
> mutateRowsWithLocks might require updatesLock.readLock with waitTime=0
> ----------------------------------------------------------------------
>
> Key: HBASE-11623
> URL: https://issues.apache.org/jira/browse/HBASE-11623
> Project: HBase
> Issue Type: Improvement
> Components: regionserver
> Affects Versions: 0.96.1.1, 0.94.21, 0.98.4
> Reporter: cuijianwei
> Assignee: cuijianwei
> Priority: Minor
> Fix For: 0.99.0, 0.98.5, 0.94.22, 2.0.0
>
> Attachments: HBASE-11623-0.94-v1.patch, HBASE-11623-trunk-v1.patch
>
>
> mutateRowsWithLocks will acquire updatesLock.readLock by the following code:
> {code}
> ...
> lock(this.updatesLock.readLock(), acquiredRowLocks.size());
> ...
> {code}
> However, acquiredRowLocks might be empty, and then the waitTime of HRegion.lock(...) will be set to 0, which will make mutateRowsWithLocks fail if can not acquire updatesLock.readLock immediately.
> In our environment, we implement a region coprocessor which need to hold row locks before invoke mutateRowsWithLocks. Then, the rowsToLock(passed to mutateRowsWithLocks) will be an empty set, and we get the following exception occasionally:
> {code}
> org.apache.hadoop.hbase.RegionTooBusyException: failed to get a lock in 0ms
> 582 at org.apache.hadoop.hbase.regionserver.HRegion.lock(HRegion.java:6191)
> 583 at org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:5126)
> 584 at org.apache.hadoop.hbase.regionserver.HRegion.mutateRowsWithLocks(HRegion.java:5034)
> ...
> {code}
> Is it reasonable that we use default waitTime when rowsToLock is empty? (as the following code)
> {code}
> lock(this.updatesLock.readLock(), acquiredRowLocks.size() == 0 ? 1 : acquiredRowLocks.size());
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)