[
https://issues.apache.org/jira/browse/HBASE-24609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17213519#comment-17213519
]
Duo Zhang commented on HBASE-24609:
-----------------------------------
{quote}
Is this plan written down anywhere?
{quote}
No, but I think this is a general rule. Do not put code in a place where no one
should use it.
{quote}
It does? Thats weird. I'd think it shouldn't. Can we fix it? Maybe balancer is
in wrong place in the dependency hierarchy then?
{quote}
Yes.
{quote}
Thats weird. I'd think it shouldn't. Can we fix it?
{quote}
I'm afraid not. Maybe we could try to avoid using MTA but favored node balancer
will store the favored nodes in the 'info' family, with a 'fn' qualifier.
{quote}
Maybe balancer is in wrong place in the dependency hierarchy then?
{quote}
I do not think so. We are trying to move code out of hbase-server as much as if
possible. We have hbase-zookeeper, hbase-replication, hbase-http. I think we
should do the same for hbase-balancer. I do not think this should be reverted
only because we do not want to put MTA in hbase-balancer.
{quote}
Class javadoc says it reads and writes.
{quote}
Will file an issue to justify the javadoc of related classes.
{quote}
MTA was one-way of getting to meta table. Now we have a client way and the MTA
to write and we also have the new utility CatalogFamilyFormat.... And I see the
RegionStateStore is getting some extra responsibility.
{quote}
I think 'accessing meta' is usually a 'fake ' requirement. What you really want
are 'get all regions of a table', 'update the location of a region', 'lookup
the location of a region' etc. Although they are stored in hbase:meta, but in
different places we have different ways to optimize it right? At client side,
we have region location cache, and at master side, we cache everything in
memory. That's why I want to completely remove the MTA. It gives users an
impression that they could access meta directly if they have a Connection
instance in hand, or they even only have a Configuration in hand they will
create a Connection and then use it to access meta, which is very easy to break
our architecture.
{quote}
Nothing wrong w/ the above. RSS was using the MTA. Sounds like you want to move
MTA into RSS?
{quote}
I would define it as 'Remove the modification methods in MTA and developpers
should always use RSS to modify region state at master side'.
{quote}
What about the comment on CatalogFamilyFormat? This class seems to be doing
what MTA was doing, what you seem to be trying to undo. Its name is odd too.
{quote}
Was I using wrong words again? It seems that you completely ignored my comments
about the CatalogFamilyFormat... It does not contain any modification methods,
just the data format related methods about the how we store data in the 'info'
family. This is the javadoc for this class
{noformat}
* Helper class for generating/parsing
* {@value org.apache.hadoop.hbase.HConstants#CATALOG_FAMILY_STR} family cells
in meta table.
* <p/>
* The cells in catalog family are:
{noformat}
And I also described why I call it 'Catalog'. I do not see your objections on
HBASE-11288. I'm neutral with the naming, just provide a word you like, If it
suits I will change the name.
Thanks.
> Move MetaTableAccessor out of hbase-client
> ------------------------------------------
>
> Key: HBASE-24609
> URL: https://issues.apache.org/jira/browse/HBASE-24609
> Project: HBase
> Issue Type: Task
> Components: amv2, Client, meta
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Major
> Fix For: 3.0.0-alpha-1
>
>
> On master branch we have AsyncMetaTableAccessor which is used at client side
> and MetaTableAccessor has lots of internal methods for implementing
> assignment, which is not part of our client code.
> So let's move it to hbase-server, and in the future, maybe in hbase-balancer?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
