[
https://issues.apache.org/jira/browse/HBASE-12035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14141893#comment-14141893
]
Mikhail Antonov commented on HBASE-12035:
-----------------------------------------
That jira is also related to the effort of abstracting hbase client in general
from ZK. Conceptually, avoiding going for such information to ZK implies having
to either go for such information elsewhere (quorum of masters, or regions
hosting meta table, if we put the mark in meta, and if meta isn't co-located),
or keeping copy of it locally on client and refreshing the cache with call to
master?
For the client-side options -assuming that table enabled/disabled information
changes rarely, and there are not tens of thousands table in the cluster, every
client can request list of table states when it established hconnection, and
then use it. It can either reload the cache by timer (once every N seconds), or
it can do so when is suspects that info in cache is obsolete (e.g. after first
retry against the region of the table believed to be enabled)?
> Client does an RPC to master everytime a region is relocated
> ------------------------------------------------------------
>
> Key: HBASE-12035
> URL: https://issues.apache.org/jira/browse/HBASE-12035
> Project: HBase
> Issue Type: Improvement
> Reporter: Enis Soztutar
> Priority: Critical
> Fix For: 2.0.0
>
>
> HBASE-7767 moved table enabled|disabled state to be kept in hdfs instead of
> zookeeper. isTableDisabled() which is used in
> HConnectionImplementation.relocateRegion() now became a master RPC call
> rather than a zookeeper client call. Since we do relocateRegion() calls
> everytime we want to relocate a region (region moved, RS down, etc) this
> implies that when the master is down, the some of the clients for uncached
> regions will be affected.
> See HBASE-7767 and HBASE-11974 for some more background.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
