[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-650433945 bq. OK, got it. So you are talking about the whole design and Im expecting you are commenting on the patch. Yeah. This patch presumes a design that is only starting to come out in our design doc. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-643352831 `Let's focus on the problems of this issue please? Stop shooting on air without any actual code...` I'm only here because I'm interested in discussion/design of meta splitting and in trying to enable collaboration around this project; there are more interested in this effort than yourself and up for helping out but its hard for others to get involved if you are doing it all. I'm only reading this PR because I'm trying to elicit your intention. It starts to emerge as we do this back and forth and as you surface to contrib. to the design doc. Without a scheme/design, I don't know what the 'problems of this issue' are. I've a good idea now after spending a bunch of time cycling through this thing. When missing a plan/design, concerns get punted to 'later' or for me to do if I want in follow-up. I owe work on the design doc. I've gotten from you some outline on intent and seems good to me. Let me write it up so others can offer opinion. Will be back here later to see if I can do a +1 for the branch commit. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-643055266 `The point here is when do you want to do this? In normal single read/write path, we just need to locate a single region. And for scanning, we need to locate to the next region when the current region is done, or for reverse scan we need to locate to the previous region. We do not need to get the location of a region and then go to the next region.` This makes sense. A catalogjanitor or scp or hbck2 doing a visit to each row would not go via this interface. It would be done internal to the master (i guess). This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-643052700 `To be honest, I do not fully get your point on why we need to stick on the RegionLocator interface. ` This is not my point. My point is re-use known API or Interfaces if they fit the usage rather than freighting in new stuff. `So let's stop arguing on this?` Not arguing. Trying to discuss. I do keep getting cornered battered with take this PR as is. `...you are free to change it at any time.` Trying to discuss to understand what is here, the direction, and to avoid having to do this explicitly. We have loads of experience in this area. The answer to suggestions or concerns can't be "...You can implement what you want in follow on issues, it is not a blocker problem here?" This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-642393168 `On locating, if you want to locate to the next region, just use the end row of the current region to locate?` Caller has to take returned location, extract end row... do proper handling if end region... when they seems more natural to just call 'next' if it an iterator/scanner-like API. On RL, point is its API seems same as what you'd add so just reuse. That it public doesn't preclude its use internal. That the public impl is ARL, doesn't stop the ConnectionRegistry hosted impl having to be the same. Your exposition above helps though in that it might confuse more than it helps if same Interface has such different impls. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [hbase] saintstack commented on pull request #1774: HBASE-24389 Introduce new master rpc methods to locate meta region through root region
saintstack commented on pull request #1774: URL: https://github.com/apache/hbase/pull/1774#issuecomment-641736719 Hopefully we can do work up front that makes it so new clients do not have to take a big pause while downloading MBs joining a big cluster. `There is no paging support in the client facing API right?` We do have 'paging' in client API; Scans (I talked of paging/iterating/cursor/scan-like API, I thought?). Here I'm advocating reuse and existing models -- e.g. RegionLocator Interface seems to have your two APIs already as you note so why wouldn't we use it instead in ConnectionRegistry? --rather than new API and new PBs. The response seems to be that its all internal so its going to be fine; sure we can make it work but if an opportunity for reuse, it could be better. We can add prefetch to the PB to 'improve' performance but the API is still one-at-a-time; consumer has to do the juggling to figure what it should pass in as the next 'row'; instead of just next'ing to get next Region. I get your bit about Scan being too much to expose. That seems good. But the model of iterating across Table results I think we should keep here; doesn't have to be full-on Scan. Master doesn't expose Scan Interface so I suppose we can't reuse Scan RPC. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
