[
https://issues.apache.org/jira/browse/HBASE-10595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13909715#comment-13909715
]
Feng Honghua commented on HBASE-10595:
--------------------------------------
Additional note: TestAssignmentManagerOnCluster#testMoveRegionOfDeletedTable
uses an assumption that regions of a deleted table are guaranteed to be removed
from RegionStates in HMaster after deleteTable() is done and expects to receive
a UnknownRegionException(which is by checking that region is not in
RegionStates) when moving a region after its table is deleted.
But this assumption is wrong because though deleteTable() is synchronous but it
only verify the table descriptor is empty before return, but in
DeleteTableHandler the regions are removed from RegionStates *after*
region-data-dirs / table-dir are removed and table descriptor is removed from
cache.
Instead of fixing it in the unit test(we could sleep for a while before call
move(), but it's weird since deleteTable() is synchronous!), I let move() throw
UnknownRegionException as well when FSTableDescriptors.get(table) return null
(means already deleted, but before regions are removed from RegionStates)
> 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: Bug
> Components: master, util
> Reporter: Feng Honghua
> Assignee: Feng Honghua
> Attachments: HBASE-10595-trunk_v1.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)
