[ 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)