Return-Path: X-Original-To: apmail-hbase-dev-archive@www.apache.org Delivered-To: apmail-hbase-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 6E0F811433 for ; Thu, 31 Jul 2014 23:57:39 +0000 (UTC) Received: (qmail 8506 invoked by uid 500); 31 Jul 2014 23:57:38 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 8401 invoked by uid 500); 31 Jul 2014 23:57:38 -0000 Mailing-List: contact dev-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@hbase.apache.org Delivered-To: mailing list dev@hbase.apache.org Received: (qmail 8388 invoked by uid 99); 31 Jul 2014 23:57:38 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Jul 2014 23:57:38 +0000 Date: Thu, 31 Jul 2014 23:57:38 +0000 (UTC) From: "Lars Hofhansl (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Resolved] (HBASE-11623) mutateRowsWithLocks might require updatesLock.readLock with waitTime=0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ 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)