[
https://issues.apache.org/jira/browse/HBASE-11623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
cuijianwei updated HBASE-11623:
-------------------------------
Description:
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}
was:
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}
> 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
> 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)
