Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Thu, 7 Jul 2011 18:37:16 +0000 (UTC)
From: "Ted Yu (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: 
 <1362171272.8398.1310063836883.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <607547126.19984.1305656507706.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Assigned] (HBASE-3893) HRegion.internalObtainRowLock
 shouldn't wait forever
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HBASE-3893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ted Yu reassigned HBASE-3893:
-----------------------------

    Assignee: Ted Yu

> HRegion.internalObtainRowLock shouldn't wait forever
> ----------------------------------------------------
>
>                 Key: HBASE-3893
>                 URL: https://issues.apache.org/jira/browse/HBASE-3893
>             Project: HBase
>          Issue Type: Improvement
>    Affects Versions: 0.90.2
>            Reporter: Jean-Daniel Cryans
>            Assignee: Ted Yu
>            Priority: Blocker
>             Fix For: 0.90.4
>
>         Attachments: 3893.txt
>
>
> We just had a weird episode where one user was trying to insert a lot of data with overlapping keys into a single region (all of that is a separate problem), and the region server rapidly filled up all it's handlers + queues with those calls. Basically it wasn't deadlocked but almost.
> Worse, now that we have a 60 seconds socket timeout the clients were eventually getting the timeout and then retrying another call to that same region server.
> We should have a timeout on lockedRows.wait() in HRegion.internalObtainRowLock in order to survive this better.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira