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)
