[
https://issues.apache.org/jira/browse/HBASE-10584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Feng Honghua updated HBASE-10584:
---------------------------------
Description:
# HBaseAdmin.tableExists is implemented by scanning meta table
# HBaseAdmin.listTables(and HBaseAdmin.getTableDescriptor) is implemented by
talking with HMaster which responses by querying the FSTableDescriptors, and
FSTableDescriptors return all tables by scanning all the table descriptor files
in FS(cache also plays here, so most of time it can be satisfied by cache)...
Actually HBaseAdmin requests HMaster to check if a table exists internally when
implementing deleteTable(see below), then why does it use a different(scanning
meta table) way to implementing tableExists() for outside user to use for the
same purpose?
{code}
tableExists = false;
GetTableDescriptorsResponse htds;
MasterKeepAliveConnection master = connection.getKeepAliveMasterService();
try {
GetTableDescriptorsRequest req =
RequestConverter.buildGetTableDescriptorsRequest(tableName);
htds = master.getTableDescriptors(null, req);
} catch (ServiceException se) {
throw ProtobufUtil.getRemoteException(se);
} finally {
master.close();
}
tableExists = !htds.getTableSchemaList().isEmpty();
{code}
(Above verifying that table descriptor file is deleted can guarantee all items
of this table are deleted from meta table...)
Since creating table descriptor files and inserting item to meta table occur in
different time without atomic semantic, this inconsistency in implementation
can lead to confusing behaviors when create-table or delete-table fails midway,
(before according cleanup is done) table descriptor file may exists while no
item exists in meta table (for create-table where table descriptor file is
created before inserting item to meta table), this leads to listTables
including that table, while tableExists says no. Similar inconsistency if
delete-table fails mid-way...
Confusing behavior can happen during the process even though eventually it
succeed:
# During table creation, when a user calls listTables and then calls
tableExists for this table after the table descriptor is created but before
item is inserted to meta table. He will find the listTables includes a table
but tableExists return false for that same table, this behavior is confusing
and should only acceptable during the table is being deleted...
# Similar behavior occurs during table deletion.
Seems the benefit of implementing tableExists this way is we can avoid talking
with HMaster, considering we talk with HMaster for listTables and
getTableDescriptor, such benefit can't offset the drawback from inconsistency.
was:
# HBaseAdmin.tableExists is implemented by scanning meta table
# HBaseAdmin.listTables(and HBaseAdmin.getTableDescriptor) is implemented by
talking with HMaster which responses by querying the FSTableDescriptors, and
FSTableDescriptors return all tables by scanning all the table descriptor files
in FS(cache also plays here, so most of time it can be satisfied by cache)...
Actually HBaseAdmin requests HMaster to check if a table exists internally when
implementing deleteTable(see below), then why does it use a different(scanning
meta table) way to implementing tableExists() for outside user to use for the
same purpose?
{code}
tableExists = false;
GetTableDescriptorsResponse htds;
MasterKeepAliveConnection master = connection.getKeepAliveMasterService();
try {
GetTableDescriptorsRequest req =
RequestConverter.buildGetTableDescriptorsRequest(tableName);
htds = master.getTableDescriptors(null, req);
} catch (ServiceException se) {
throw ProtobufUtil.getRemoteException(se);
} finally {
master.close();
}
tableExists = !htds.getTableSchemaList().isEmpty();
{code}
Since creating table descriptor files and inserting item to meta table occur in
different time without atomic semantic, this inconsistency in implementation
can lead to confusing behaviors when create-table or delete-table fails midway,
(before according cleanup is done) table descriptor file may exists while no
item exists in meta table (for create-table where table descriptor file is
created before inserting item to meta table), this leads to listTables
including that table, while tableExists says no. Similar inconsistency if
delete-table fails mid-way...
Confusing behavior can happen during the process even though eventually it
succeed:
# During table creation, when a user calls listTables and then calls
tableExists for this table after the table descriptor is created but before
item is inserted to meta table. He will find the listTables includes a table
but tableExists return false for that same table, this behavior is confusing
and should only acceptable during the table is being deleted...
# Similar behavior occurs during table deletion.
Seems the benefit of implementing tableExists this way is we can avoid talking
with HMaster, considering we talk with HMaster for listTables and
getTableDescriptor, such benefit can't offset the drawback from inconsistency.
> Inconsistency between tableExists and listTables in implementation
> ------------------------------------------------------------------
>
> Key: HBASE-10584
> URL: https://issues.apache.org/jira/browse/HBASE-10584
> Project: HBase
> Issue Type: Bug
> Components: Client, master
> Reporter: Feng Honghua
> Assignee: Feng Honghua
>
> # HBaseAdmin.tableExists is implemented by scanning meta table
> # HBaseAdmin.listTables(and HBaseAdmin.getTableDescriptor) is implemented by
> talking with HMaster which responses by querying the FSTableDescriptors, and
> FSTableDescriptors return all tables by scanning all the table descriptor
> files in FS(cache also plays here, so most of time it can be satisfied by
> cache)...
> Actually HBaseAdmin requests HMaster to check if a table exists internally
> when implementing deleteTable(see below), then why does it use a
> different(scanning meta table) way to implementing tableExists() for outside
> user to use for the same purpose?
> {code}
> tableExists = false;
> GetTableDescriptorsResponse htds;
> MasterKeepAliveConnection master = connection.getKeepAliveMasterService();
> try {
> GetTableDescriptorsRequest req =
> RequestConverter.buildGetTableDescriptorsRequest(tableName);
> htds = master.getTableDescriptors(null, req);
> } catch (ServiceException se) {
> throw ProtobufUtil.getRemoteException(se);
> } finally {
> master.close();
> }
> tableExists = !htds.getTableSchemaList().isEmpty();
> {code}
> (Above verifying that table descriptor file is deleted can guarantee all
> items of this table are deleted from meta table...)
> Since creating table descriptor files and inserting item to meta table occur
> in different time without atomic semantic, this inconsistency in
> implementation can lead to confusing behaviors when create-table or
> delete-table fails midway, (before according cleanup is done) table
> descriptor file may exists while no item exists in meta table (for
> create-table where table descriptor file is created before inserting item to
> meta table), this leads to listTables including that table, while tableExists
> says no. Similar inconsistency if delete-table fails mid-way...
> Confusing behavior can happen during the process even though eventually it
> succeed:
> # During table creation, when a user calls listTables and then calls
> tableExists for this table after the table descriptor is created but before
> item is inserted to meta table. He will find the listTables includes a table
> but tableExists return false for that same table, this behavior is confusing
> and should only acceptable during the table is being deleted...
> # Similar behavior occurs during table deletion.
> Seems the benefit of implementing tableExists this way is we can avoid
> talking with HMaster, considering we talk with HMaster for listTables and
> getTableDescriptor, such benefit can't offset the drawback from inconsistency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
