[
https://issues.apache.org/jira/browse/HBASE-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14143434#comment-14143434
]
stack commented on HBASE-7767:
------------------------------
bq. but from code point of view there will be may if table == 'tables' ugly
code.
Yes. This would be ugly.
bq. and table doesn't solve scaling well, it still will be one rs/master which
will response for requests (replicas can be here, but they will not be
consistent).
Could split it to divide up the work! (Now I am being silly)
bq. that can be made lazy, region server can hold short-lived cache for table
info (state, schema) and throttle client requests.
This is good.
What to do about client connecting to cluster for first time? It goes to
master to ask if enabled/disabled in HTable constructor IIRC. We should just
remove that? Let it scan meta for table info and then on first acces, it will
get the TDE (or some such?)
> Get rid of ZKTable, and table enable/disable state in ZK
> ---------------------------------------------------------
>
> Key: HBASE-7767
> URL: https://issues.apache.org/jira/browse/HBASE-7767
> Project: HBase
> Issue Type: Sub-task
> Components: Zookeeper
> Affects Versions: 2.0.0
> Reporter: Enis Soztutar
> Assignee: Andrey Stepachev
> Fix For: 2.0.0
>
> Attachments:
> 0001-HBASE-7767-Get-rid-of-ZKTable-and-table-enable-disab.patch,
> 0001-rebase.patch, 7767v2.txt, HBASE-7767.patch, HBASE-7767.patch,
> HBASE-7767.patch, HBASE-7767.patch, HBASE-7767.patch, HBASE-7767.patch,
> HBASE-7767.patch, HBASE-7767.patch, HBASE-7767.patch, HBASE-7767.patch,
> HBASE-7767.patch, HBASE-7767.patch, HBASE-7767.patch
>
>
> As discussed table state in zookeeper for enable/disable state breaks our
> zookeeper contract. It is also very intrusive, used from the client side,
> master and region servers. We should get rid of it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
