[
https://issues.apache.org/jira/browse/HBASE-22417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16877358#comment-16877358
]
stack commented on HBASE-22417:
-------------------------------
bq. One alternative to fix this then was swapping order of stages in
DeleteTableProcedure, starting with DELETE_TABLE_CLEAR_FS_LAYOUT, then moving
to DELETE_TABLE_REMOVE_FROM_META.
Sounds good to me.
DELETE_TABLE_CLEAR_FS_LAYOUT case is not in same location as other case items.
Patch looks good.
> DeleteTableProcedure.deleteFromMeta method should remove table from Master's
> table descriptors cache
> ----------------------------------------------------------------------------------------------------
>
> Key: HBASE-22417
> URL: https://issues.apache.org/jira/browse/HBASE-22417
> Project: HBase
> Issue Type: Bug
> Reporter: Wellington Chevreuil
> Assignee: Wellington Chevreuil
> Priority: Major
> Attachments: HBASE-22417.master.001.patch,
> HBASE-22417.master.002.patch
>
>
> DeleteTableProcedure defines a static deleteFromMeta method that's currently
> used both by DeleteTableProcedure itself and TruncateTableProcedure.
> Sometimes, depending on the table size (and under slower, under performing
> FileSystems), truncation can take longer to complete
> *TRUNCATE_TABLE_CLEAR_FS_LAYOUT* stage, but the given table has already been
> deleted from meta on previous *TRUNCATE_TABLE_REMOVE_FROM_META* stage. In
> this case, features relying on Master's table descriptor's cache might
> wrongly try to reference this truncating table. Master Web UI, for example,
> would try to check this table state and end up showing a 500 error.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
