[jira] [Created] (HBASE-30383) Migrate RegionServer block cache ownership to CacheAccessService

["Vladimir Rodionov (Jira)" <ji...@apache.org>]

Vladimir Rodionov created HBASE-30383:
-----------------------------------------

             Summary: Migrate RegionServer block cache ownership to CacheAccessService
                 Key: HBASE-30383
                 URL: https://issues.apache.org/jira/browse/HBASE-30383
             Project: HBase
          Issue Type: New Feature
            Reporter: Vladimir Rodionov
            Assignee: Vladimir Rodionov
             Fix For: 4.0.0-alpha-1


Migrate the RegionServer runtime from owning and exposing a legacy BlockCache to using CacheAccessService as the primary block-cache access abstraction.

Currently, HRegionServer creates the block cache through BlockCacheFactory.createBlockCache() and stores it as a BlockCache. This keeps the production RegionServer path tied to legacy implementations such as LruBlockCache, CombinedBlockCache, and InclusiveCombinedBlockCache, even though the new cache architecture supports native CacheEngine implementations and explicit CacheTopology implementations.

HRegionServer should instead construct and own a CacheAccessService using the new configuration-based construction path. This allows native CacheEngine implementations, such as LruCacheEngine, to be used directly without first constructing a BlockCache and adapting it through BlockCacheBackedCacheEngine.

The migration should propagate CacheAccessService through RegionServerServices, HRegion, and HStore so that CacheConfig is constructed using CacheAccessService rather than BlockCache.

The current RegionServer cache ownership path is approximately:



{code:java}
HRegionServer
    |
    +-- BlockCacheFactory.createBlockCache()
    |
    +-- BlockCache
            |
            +-- LruBlockCache
            |
            +-- CombinedBlockCache
                    |
                    +-- L1
                    +-- L2
{code}


The target path should be:

{code:java}
Configuration
    |
    v
CacheAccessServices.fromConfiguration(...)
    |
    v
CacheEngine(s)
    |
    v
CacheTopology
    |
    v
CacheAccessService
    |
    +-- HRegion
            |
            v
          HStore
            |
            v
        CacheConfig
{code}

For the LRU policy, the production RegionServer path should use LruCacheEngine directly rather than:

{code:java}
LruBlockCache
    -> BlockCacheBackedCacheEngine
{code}

The existing RegionServerServices.getBlockCache() API and other legacy BlockCache consumers may be retained temporarily where required for compatibility. However, the migration must not require constructing a duplicate legacy BlockCache alongside the new CacheAccessService.

The migration should also address RegionServer operations that currently access BlockCache directly, including cache shutdown, HFile eviction, metrics/reporting, and graceful-stop cache handling.

Capabilities that require additional abstractions, such as dynamic L1 resizing by HeapMemoryManager, may be migrated separately.

Scope:
 
* Make CacheAccessService the primary block-cache object owned by HRegionServer.
* Construct the service through CacheAccessServices.fromConfiguration(...).
* Add CacheAccessService access to RegionServerServices.
* Propagate CacheAccessService from HRegionServer to HRegion.
* Update HStore to construct CacheConfig using CacheAccessService.
* Migrate direct RegionServer cache operations such as shutdown and HFile eviction to CacheAccessService.
* Update cache metrics/reporting where the required information is already exposed by the new cache abstractions.
* Remove the production data-path dependency on BlockCacheFactory.createBlockCache().
* Preserve legacy compatibility APIs where necessary during migration.
* Do not construct a second legacy BlockCache solely to support compatibility consumers.

Out of Scope:

* Dynamic cache resizing performed by HeapMemoryManager. This may require a native CacheEngine capability analogous to ResizableBlockCache.
* Configuration-change propagation through CacheAccessService. This is handled separately.
* Migration of remaining legacy BlockCache implementations to native CacheEngine implementations.

Acceptance Criteria:

* HRegionServer owns and uses CacheAccessService as its primary block-cache abstraction.
* HRegion and HStore receive cache access through CacheAccessService.
* CacheConfig used by the RegionServer data path is constructed using CacheAccessService.
* LRU configuration results in the production RegionServer using LruCacheEngine directly.
* LruBlockCache is not created merely to provide a BlockCache compatibility object for the native LruCacheEngine.
* No duplicate cache instances are created during the migration.
* Existing RegionServer, HRegion, HStore, and HFile cache behavior remains compatible.
* Existing relevant tests continue to pass.



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