[
https://issues.apache.org/jira/browse/HBASE-13254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364012#comment-14364012
]
Stephen Yuan Jiang commented on HBASE-13254:
--------------------------------------------
[~rajeshbabu] HBASE-10215 is no longer valid in master branch, as HBASE-7767
removed the ZK table that tracks enable/disable state. So we should be safely
remove
'this.assignmentManager.getTableStateManager().setDeletedTable(tableName)'
statement.
In Branch-1, no need to fix, as the code throws TableNotFoundException after
setting up ZK table state.
[~octo47] Please let me know if you think that we should keep the
'this.assignmentManager.getTableStateManager().setDeletedTable(tableName);'
statement. The plan for me is to simply throw TableNotFoundException if table
does not exist.
> 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<TableName> 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.
> note: this bug only applies to master, a regression from HBASE-7767.
> Branch-1 has the correct logic, after setting table state, it would throw the
> exception.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
