[
https://issues.apache.org/jira/browse/HBASE-30383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on HBASE-30383 started by Vladimir Rodionov.
-------------------------------------------------
> 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
> Priority: Major
> 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)
