[
https://issues.apache.org/jira/browse/HBASE-22417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16841242#comment-16841242
]
Wellington Chevreuil commented on HBASE-22417:
----------------------------------------------
Right, the test failures are legit. We can't simply clear *descriptors cache*
on _deleteFromMeta_ because it also summarily remove table dirs on the FS. That
direct impacts snasphots, as that now would happen before _deleteFromFs_ is
executed, which is where table dirs/files are actually moved to archive first.
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. Any thoughts on this, [~xucang]?
> 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
>
>
> 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)
