[
https://issues.apache.org/jira/browse/HBASE-11288?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17177667#comment-17177667
]
Francis Christopher Liu commented on HBASE-11288:
-------------------------------------------------
I see apologies I thought you wanted my thoughts I missed the question. As
mentioned root is half of Catalog its responsibilities are similar to that of
the meta table. The benefit to root being a table just like meta is a table is
when we need to do/apply something to Catalog we can come up with a generalized
approach that can be done/applied to both. Having a generalized approach we
avoid unneeded complexities hence my questions about it being worth it, etc.
Does that answer your question?
I see in your solution is root a table like meta table would the code paths be
more or less the same? Would we be able to apply generalized solutions for both
or would they be different code paths? Are these changes in the splittable-meta
branch?
Yes indeed it’s good to know the proc-v2 is stable and working well. Makes me
look forward to deploying hbase-2 a bit more. I think the intent would be to
pick one and stick with it for a long time. Hence the rigor in deliberation. In
which case would adding new states in SCP still be a concern?
I see I apologize if I sounded pushy I did not mean to. There could be other
solutions that are good, but if the solution involves specializing then I’d
also like to understand whether that tradeoff is compelling. There could be
reasons that would make that tradeoff compelling I just don't know about it. If
there was a compelling reason as mentioned I would change my current thinking
on "local region on master".
> Splittable Meta
> ---------------
>
> Key: HBASE-11288
> URL: https://issues.apache.org/jira/browse/HBASE-11288
> Project: HBase
> Issue Type: Umbrella
> Components: meta
> Reporter: Francis Christopher Liu
> Assignee: Francis Christopher Liu
> Priority: Major
> Attachments: jstack20200807_bad_rpc_priority.txt, root_priority.patch
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)