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 03721D137 for ; Thu, 6 Sep 2012 17:19:08 +0000 (UTC) Received: (qmail 72555 invoked by uid 500); 6 Sep 2012 17:19:07 -0000 Delivered-To: apmail-hbase-issues-archive@hbase.apache.org Received: (qmail 72424 invoked by uid 500); 6 Sep 2012 17:19:07 -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 72415 invoked by uid 99); 6 Sep 2012 17:19:07 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Sep 2012 17:19:07 +0000 Date: Fri, 7 Sep 2012 04:19:07 +1100 (NCT) From: "ramkrishna.s.vasudevan (JIRA)" To: issues@hbase.apache.org Message-ID: <834246137.45336.1346951947757.JavaMail.jiratomcat@arcas> In-Reply-To: <1809290185.4265.1337626541081.JavaMail.jiratomcat@issues-vm> Subject: [jira] [Commented] (HBASE-6060) Regions's in OPENING state from failed regionservers takes a long time to recover 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-6060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13449825#comment-13449825 ] ramkrishna.s.vasudevan commented on HBASE-6060: ----------------------------------------------- @Stack Recently Jon's mail thread on rewriting AM altogether implies that the scenario mentioned here also will be covered ? > Regions's in OPENING state from failed regionservers takes a long time to recover > --------------------------------------------------------------------------------- > > Key: HBASE-6060 > URL: https://issues.apache.org/jira/browse/HBASE-6060 > Project: HBase > Issue Type: Bug > Components: master, regionserver > Reporter: Enis Soztutar > Assignee: rajeshbabu > Fix For: 0.96.0, 0.92.3, 0.94.3 > > Attachments: 6060-94-v3.patch, 6060-94-v4_1.patch, 6060-94-v4_1.patch, 6060-94-v4.patch, 6060_alternative_suggestion.txt, 6060_suggestion2_based_off_v3.patch, 6060_suggestion_based_off_v3.patch, 6060_suggestion_toassign_rs_wentdown_beforerequest.patch, 6060-trunk_2.patch, 6060-trunk_3.patch, 6060-trunk.patch, 6060-trunk.patch, HBASE-6060-92.patch, HBASE-6060-94.patch, HBASE-6060_latest.patch, HBASE-6060_latest.patch, HBASE-6060_latest.patch, HBASE-6060-trunk_4.patch, HBASE-6060_trunk_5.patch > > > we have seen a pattern in tests, that the regions are stuck in OPENING state for a very long time when the region server who is opening the region fails. My understanding of the process: > > - master calls rs to open the region. If rs is offline, a new plan is generated (a new rs is chosen). RegionState is set to PENDING_OPEN (only in master memory, zk still shows OFFLINE). See HRegionServer.openRegion(), HMaster.assign() > - RegionServer, starts opening a region, changes the state in znode. But that znode is not ephemeral. (see ZkAssign) > - Rs transitions zk node from OFFLINE to OPENING. See OpenRegionHandler.process() > - rs then opens the region, and changes znode from OPENING to OPENED > - when rs is killed between OPENING and OPENED states, then zk shows OPENING state, and the master just waits for rs to change the region state, but since rs is down, that wont happen. > - There is a AssignmentManager.TimeoutMonitor, which does exactly guard against these kind of conditions. It periodically checks (every 10 sec by default) the regions in transition to see whether they timedout (hbase.master.assignment.timeoutmonitor.timeout). Default timeout is 30 min, which explains what you and I are seeing. > - ServerShutdownHandler in Master does not reassign regions in OPENING state, although it handles other states. > Lowering that threshold from the configuration is one option, but still I think we can do better. > Will investigate more. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira