Return-Path: X-Original-To: apmail-hbase-issues-archive@www.apache.org Delivered-To: apmail-hbase-issues-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9D2D211680 for ; Wed, 16 Apr 2014 02:38:19 +0000 (UTC) Received: (qmail 8285 invoked by uid 500); 16 Apr 2014 02:38:17 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 8203 invoked by uid 500); 16 Apr 2014 02:38:16 -0000 Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list issues@hbase.apache.org Received: (qmail 8170 invoked by uid 99); 16 Apr 2014 02:38:15 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 16 Apr 2014 02:38:15 +0000 Date: Wed, 16 Apr 2014 02:38:15 +0000 (UTC) From: "Jimmy Xiang (JIRA)" To: issues@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (HBASE-10871) Indefinite OPEN/CLOSE wait on busy RegionServers 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-10871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13970364#comment-13970364 ] Jimmy Xiang commented on HBASE-10871: ------------------------------------- I think some delay should help, for example, sleep 100ms? So that either the server is not busy any more, or ServerManager has a chance to know the server is down. Continuously retry doesn't help too much in this case. > Indefinite OPEN/CLOSE wait on busy RegionServers > ------------------------------------------------ > > Key: HBASE-10871 > URL: https://issues.apache.org/jira/browse/HBASE-10871 > Project: HBase > Issue Type: Improvement > Components: Balancer, master, Region Assignment > Affects Versions: 0.94.6 > Reporter: Harsh J > > We observed a case where, when a specific RS got bombarded by a large amount of regular requests, spiking and filling up its RPC queue, the balancer's invoked unassigns and assigns for regions that dealt with this server entered into an indefinite retry loop. > The regions specifically began waiting in PENDING_CLOSE/PENDING_OPEN states indefinitely cause of the HBase Client RPC from the ServerManager at the master was running into SocketTimeouts. This caused a region unavailability in the server for the affected regions. The timeout monitor retry default of 30m in 0.94's AM compounded the waiting gap further a bit more (this is now 10m in 0.95+'s new AM, and has further retries before we get there, which is good). > Wonder if there's a way to improve this situation generally. PENDING_OPENs may be easy to handle - we can switch them out and move them elsewhere. PENDING_CLOSEs may be a bit more tricky, but there must perhaps at least be a way to "give up" permanently on a movement plan, and letting things be for a while hoping for the RS to recover itself on its own (such that clients also have a chance of getting things to work in the meantime)? -- This message was sent by Atlassian JIRA (v6.2#6252)