hbase-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "cuijianwei (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HBASE-11623) mutateRowsWithLocks might require updatesLock.readLock with waitTime=0
Date Thu, 31 Jul 2014 04:50:39 GMT
cuijianwei created HBASE-11623:
----------------------------------

             Summary: 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.98.4, 0.94.21, 0.96.1.1
            Reporter: cuijianwei
            Priority: Minor


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)

Mime
View raw message