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 6768617937 for ; Mon, 16 Mar 2015 21:23:41 +0000 (UTC) Received: (qmail 46841 invoked by uid 500); 16 Mar 2015 21:23:40 -0000 Delivered-To: apmail-hbase-dev-archive@hbase.apache.org Received: (qmail 46756 invoked by uid 500); 16 Mar 2015 21:23:40 -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 46743 invoked by uid 99); 16 Mar 2015 21:23:40 -0000 Received: from arcas.apache.org (HELO arcas.apache.org) (140.211.11.28) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 16 Mar 2015 21:23:40 +0000 Date: Mon, 16 Mar 2015 21:23:40 +0000 (UTC) From: "Stephen Yuan Jiang (JIRA)" To: dev@hbase.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Created] (HBASE-13254) EnableTableHandler#prepare would not throw TableNotFoundException during recovery MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 Stephen Yuan Jiang created HBASE-13254: ------------------------------------------ Summary: EnableTableHandler#prepare would not throw TableNotFoundException during recovery Key: HBASE-13254 URL: https://issues.apache.org/jira/browse/HBASE-13254 Project: HBase Issue Type: Bug Reporter: Stephen Yuan Jiang Assignee: Stephen Yuan Jiang Priority: Minor During recovery, when EnableTableHandler#prepare() is called, If the table does not exist, it marks the table as deleted and does NOT throw TableNotFoundException. The result is that the table lock is released and the caller has no knowledge that the table not exist or already deleted, it would continue the next step. {code} public EnableTableHandler prepare() throws TableNotFoundException, TableNotDisabledException, IOException { ... try { // Check if table exists if (!MetaTableAccessor.tableExists(this.server.getConnection(), tableName)) { // retainAssignment is true only during recovery. In normal case it is false if (!this.skipTableStateCheck) { throw new TableNotFoundException(tableName); } this.assignmentManager.getTableStateManager().setDeletedTable(tableName); } ... } {code} However,look at the recovery code that calls the EnableTableHandler#prepare function, AssignmentManager#recoverTableInEnablingState() expects TableNotFoundException so that it can skip the table. {code} private void recoverTableInEnablingState() throws KeeperException, IOException { Set enablingTables = tableStateManager. getTablesInStates(TableState.State.ENABLING); if (enablingTables.size() != 0) { for (TableName tableName : enablingTables) { // Recover by calling EnableTableHandler LOG.info("The table " + tableName + " is in ENABLING state. Hence recovering by moving the table" + " to ENABLED state."); // enableTable in sync way during master startup, // no need to invoke coprocessor EnableTableHandler eth = new EnableTableHandler(this.server, tableName, this, tableLockManager, true); try { eth.prepare(); } catch (TableNotFoundException e) { LOG.warn("Table " + tableName + " not found in hbase:meta to recover."); continue; } eth.process(); } } } {code} The proposed fix is always throw TableNotFoundException in EnableTableHandler#prepare if the table does not exist. -- This message was sent by Atlassian JIRA (v6.3.4#6332)