[
https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916180#comment-13916180
]
Enis Soztutar commented on HBASE-10595:
---------------------------------------
bq. You meant HMaster when saying 'NN', right?
I meant NameNode, not HMaster.
bq. In the time interval that after table dir is moved to tmp folder and before
it's removed from table descriptor cache, the results of listTables and
getTableDescriptor contradict, don't you think it's a kind of inconsistency?
That is an inconsistency. But completely making the cache useless is not the
way to solve it I think.
bq. Users are surely NOT expected to delete table directory on purpose, but if
they do delete table directory by accident, we should still ensure queries on
HBase states get consistent results, right? Actually some HBCK unit tests aim
for ensuring consistency under such corruption from user.
That is the job of HBCK. There is no guarantees expected from the master if the
user deletes dirs under it.
> HBaseAdmin.getTableDescriptor can wrongly get the previous table's
> TableDescriptor even after the table dir in hdfs is removed
> ------------------------------------------------------------------------------------------------------------------------------
>
> Key: HBASE-10595
> URL: https://issues.apache.org/jira/browse/HBASE-10595
> Project: HBase
> Issue Type: Sub-task
> Components: master, util
> Reporter: Feng Honghua
> Assignee: Feng Honghua
> Attachments: HBASE-10595-trunk_v1.patch, HBASE-10595-trunk_v2.patch,
> HBASE-10595-trunk_v3.patch, HBASE-10595-trunk_v4.patch
>
>
> When a table dir (in hdfs) is removed(by outside), HMaster will still return
> the cached TableDescriptor to client for getTableDescriptor request.
> On the contrary, HBaseAdmin.listTables() is handled correctly in current
> implementation, for a table whose table dir in hdfs is removed by outside,
> getTableDescriptor can still retrieve back a valid (old) table descriptor,
> while listTables says it doesn't exist, this is inconsistent
> The reason for this bug is because HMaster (via FSTableDescriptors) doesn't
> check if the table dir exists for getTableDescriptor() request, (while it
> lists all existing table dirs(not firstly respects cache) and returns
> accordingly for listTables() request)
> When a table is deleted via deleteTable, the cache will be cleared after the
> table dir and tableInfo file is removed, listTables/getTableDescriptor
> inconsistency should be transient(though still exists, when table dir is
> removed while cache is not cleared) and harder to expose
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
