You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Sanjeet Malhotra (Jira)" <ji...@apache.org> on 2026/05/14 09:48:00 UTC

[jira] [Work started] (HBASE-30161) Add paginated, single-RPC RegionLocator.getRegionLocations(startKey, limit) API for bulk meta-cache warmup

     [ https://issues.apache.org/jira/browse/HBASE-30161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Work on HBASE-30161 started by Sanjeet Malhotra.
------------------------------------------------
> Add paginated, single-RPC RegionLocator.getRegionLocations(startKey, limit) API for bulk meta-cache warmup
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: HBASE-30161
>                 URL: https://issues.apache.org/jira/browse/HBASE-30161
>             Project: HBase
>          Issue Type: Improvement
>            Reporter: Sanjeet Malhotra
>            Assignee: Sanjeet Malhotra
>            Priority: Major
>              Labels: pull-request-available
>
> `RegionLocator.getAllRegionLocations()` is currently the only bulk API                       
>   to fetch all region locations of a table. Internally it opens a
>   `ResultScanner` against `hbase:meta` via                                                     
>   `MetaTableAccessor.scanMetaForTableRegions(...)` and drives                                  
>   `scanner.next()` in a loop — so the number of RPCs is                                        
>   `ceil(numRegions / hbase.meta.scanner.caching)`.                                             
>                                                                                                
>   This is a problem for clients (e.g. Phoenix) that want to perform a                          
>   *bulk warmup* of their region-location cache after a fresh JVM start                         
>   while serializing meta access. The natural pattern is to wrap the call                       
>   in a lock — mirroring what `ConnectionImplementation.locateRegionInMeta`                     
>   already does for single-region lookups via `userRegionLock`. But                             
>   because `getAllRegionLocations()` does N RPCs under one logical call:                        
>                                                                                                
>   * The lock-timeout budget has to grow with table size — there is no                          
>     sensible fixed value that works for both 10-region and 10000-region                        
>     tables.                                                                                    
>   * A single slow RPC inside the loop blocks all other meta lookups for
>     the duration.                                                                              
>   * Per-call duration is no longer constant w.r.t. data volume.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)