[jira] [Resolved] (HBASE-30305) Replace CombinedBlockCache orchestration with TieredExclusiveTopology-backed CacheAccessService

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

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

Vladimir Rodionov resolved HBASE-30305.
---------------------------------------
    Fix Version/s: 4.0.0-alpha-1
       Resolution: Implemented

> Replace CombinedBlockCache orchestration with TieredExclusiveTopology-backed CacheAccessService
> -----------------------------------------------------------------------------------------------
>
>                 Key: HBASE-30305
>                 URL: https://issues.apache.org/jira/browse/HBASE-30305
>             Project: HBase
>          Issue Type: New Feature
>          Components: BlockCache, Performance
>    Affects Versions: 4.0.0-alpha-1
>            Reporter: Vladimir Rodionov
>            Assignee: Vladimir Rodionov
>            Priority: Major
>              Labels: pull-request-available
>             Fix For: 4.0.0-alpha-1
>
>
> h3. Description
> HBASE-30024 introduced BlockCacheBackedCacheEngine, allowing existing BlockCache
> implementations to participate as CacheEngine instances.
> HBASE-30025 added the construction path for creating a TopologyBackedCacheAccessService
> from existing L1 and L2 BlockCache instances using TieredExclusiveTopology.
> The next step is to replace CombinedBlockCache as the primary L1/L2 orchestration object
> used by CacheAccessService.
> Today, the combined block cache path is assembled as:
>   LruBlockCache + BucketCache
>     -> CombinedBlockCache
>         -> BlockCacheBackedCacheAccessService
> This ticket should change the CacheAccessService construction path to use:
>   LruBlockCache + BucketCache
>     -> BlockCacheBackedCacheEngine
>         -> TieredExclusiveTopology
>             -> TopologyBackedCacheAccessService
> CombinedBlockCache should not be removed in this ticket. It should remain available for
> legacy APIs, diagnostics, tests, and any code paths that still require a BlockCache instance.
> However, new cache access should no longer depend on CombinedBlockCache for tiered
> orchestration.
> The goal is to make TieredExclusiveTopology the primary orchestration model for the
> combined L1/L2 cache path while preserving existing behavior and keeping CombinedBlockCache
> as a compatibility object.
> h3. Scope
>  * Change CacheConfig / BlockCacheFactory construction so CacheAccessService for combined
>   L1/L2 cache uses TopologyBackedCacheAccessService.
>  * Reuse TopologyBackedCacheAccessServices.fromTieredExclusiveBlockCaches(...).
>  * Keep LruBlockCache and BucketCache as existing BlockCache implementations underneath.
>  * Keep CombinedBlockCache class in the source tree.
>  * Keep any existing BlockCache-returning APIs working if they still need to expose a
>   CombinedBlockCache or legacy BlockCache view.
>  * Add tests proving the CacheAccessService path no longer wraps CombinedBlockCache when
>   L1/L2 combined cache is enabled.
>  * Add compatibility tests proving the old BlockCache view, if still exposed, remains usable.
> h3. Out of scope
>  * Do not delete CombinedBlockCache.
>  * Do not migrate LruBlockCache or BucketCache to implement CacheEngine directly yet.
>  * Do not remove BlockCacheBackedCacheAccessService.
>  * Do not migrate JSP/admin diagnostics yet unless required by compilation.
>  * Do not remove CombinedBlockCache tests yet.



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