[ 
https://issues.apache.org/jira/browse/HBASE-16060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16357955#comment-16357955
 ] 

stack commented on HBASE-16060:
-------------------------------

So, it is interesting. Finding a few issues in here like:

+ If a cluster is restarted, and table is disabled, we don't do right thing 
(comes of our recent change where we mark new Regions as CLOSED). Fixing.
+ Also, need to figure w/ this bit of code....

    // migrating existent table state from zk, so splitters
    // and recovery process treat states properly.
    // TODO: There is a problem here. There is no guarantee tht 
tableStateManager#start has
    // been called but we are using it below anyways (needs hbase:meta online 
which may not be
    // the case yet). Also,
    for (Map.Entry<TableName, TableState.State> entry : ZKDataMigrator
        .queryForTableStates(getZooKeeper()).entrySet()) {
      LOG.info("Converting state from zk to new states:" + entry);
      tableStateManager.setTableState(entry.getKey(), entry.getValue());
    }

Its a migration from zk to hbase:meta of table state but how to tell when 
migration is done?

Will be back.

> 1.x clients cannot access table state talking to 2.0 cluster
> ------------------------------------------------------------
>
>                 Key: HBASE-16060
>                 URL: https://issues.apache.org/jira/browse/HBASE-16060
>             Project: HBase
>          Issue Type: Bug
>            Reporter: Enis Soztutar
>            Assignee: stack
>            Priority: Blocker
>             Fix For: 2.0.0-beta-2
>
>         Attachments: 
> 0002-HBASE-16060-1.x-clients-cannot-access-table-state-ta.patch, 
> HBASE-16060.branch-2.001.patch
>
>
> Since table state is migrated to meta instead of zk in 2.0, 1.x clients 
> talking to 2.0 cluster cannot access the table state. This causes some weird 
> behavior since from a client perspective, {{Admin.isTableEnabled()}} and 
> {{Admin.isTableDisabled()}} both return false. 
> One option we can do is to add code in 1.x clients so that they can access 
> the table state in meta if needed. Otherwise, we can mirror the table state 
> in zk (while keeping meta as the source of truth) during 2.x lifecycle so 
> that any 1.x client can still work correctly. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to