[
https://issues.apache.org/jira/browse/HBASE-23103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16944935#comment-16944935
]
Michael Stack edited comment on HBASE-23103 at 10/5/19 12:42 AM:
-----------------------------------------------------------------
That make for a bunch of loading.
Reviewing the code base, the AsyncRpcRetryingCaller is only non-admin,
non-local (i.e. call made by the Master) apart from a swath of calling done by
thrift (which seems wrong). Let me take a look... That said, I like being
reminded that Master not be in read/write path. It is unavoidable when it comes
to Admin function but it should not be inline for read/write path.
I see the cited code was added explicitly to handle case of table being
disabled under a client.
I suppose could do an alternative that does not go to Master where for example,
MetaTableAccessor handles lookups for meta table itself (so client has only one
place to check). I could extend the meta table znode so it had a status too and
the MTA could ping this when asked of the meta state. This is not as sweet as
going to Master and not as performant given Master has cache... but does move
load off Master to elsewhere.
Interested in other suggestions.
was (Author: stack):
That make for a bunch of loading.
Reviewing the code base, the AsyncRpcRetryingCaller is only non-admin,
non-local (i.e. call made by the Master) apart from a swath of calling done by
thrift (which seems wrong). Let me take a look... That said, I like being
reminded that Master not be in read/write path. It is unavoidable when it comes
to Admin function but it should not be inline for read/write path.
I see the cited code was added explicitly to handle case of table being
disabled under a client.
I suppose could do an alternative that does not go to Master where for example,
MetaTableAccessor handles lookups for meta table itself (so client has only one
place to check). I could extend the meta table znode so it had a status too and
the MTA could ping this when asked of the meta state.
Interested in other suggestions.
> Survey incidence of table state queries
> ---------------------------------------
>
> Key: HBASE-23103
> URL: https://issues.apache.org/jira/browse/HBASE-23103
> Project: HBase
> Issue Type: Sub-task
> Reporter: Michael Stack
> Priority: Blocker
> Fix For: 3.0.0
>
>
> Task that comes of parent issue. Parent makes it so we go via Master to
> figure state of a table. It is the authority and since the parent issues adds
> being able to enable/disable hbase:meta, table state is now in two places --
> in hbase:meta table... and elsewhere for the hbase:meta's state. Rather than
> have client go to two locations dependent on which table is being asked
> about, parent made it so we went to master. Parent allows that this puts more
> load on the Master. [~zhangduo] brings up the valid concern that it might be
> too much or that dependent on the Master for state puts Master too much
> in-line with read/writes.
> This issue is a survey to figure how much load and how much state-in-master
> could mess up inline read/writes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
