[
https://issues.apache.org/jira/browse/HBASE-30205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov reassigned HBASE-30205:
-----------------------------------------
Assignee: Vladimir Rodionov
> Add CacheAccessService factory helpers for legacy BlockCache-backed
> implementations
> -----------------------------------------------------------------------------------
>
> Key: HBASE-30205
> URL: https://issues.apache.org/jira/browse/HBASE-30205
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
> Affects Versions: 4.0.0-alpha-1
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
>
> As part of the pluggable block cache refactoring, CacheAccessService is
> becoming the HBase-facing facade for block cache lookup, insertion,
> invalidation, and lifecycle operations.
> Currently, CacheAccessService can be obtained from CacheConfig, where an
> existing BlockCache instance is wrapped by
> BlockCacheBackedCacheAccessService. This works for production paths that
> already have CacheConfig, but it is inconvenient for tests and other code
> paths that directly instantiate concrete BlockCache implementations such as
> LruBlockCache, LruAdaptiveBlockCache, TinyLfuBlockCache, or BucketCache.
> There are still many valid direct uses of concrete BlockCache
> implementations, especially in unit tests that verify cache-specific
> behavior. Those tests should not be mechanically migrated away from concrete
> cache constructors. However, tests and integration code that need to exercise
> the new CacheAccessService-facing path should have a simple factory method
> for wrapping an existing BlockCache instance.
> Proposed approach:
> * Add factory helpers to CacheAccessServices for creating CacheAccessService
> instances from existing BlockCache objects.
> * Support wrapping both direct BlockCache instances and Optional<BlockCache>.
> * Return a disabled/no-op CacheAccessService when the optional BlockCache is
> empty.
> * Keep existing concrete BlockCache constructors unchanged.
> * Keep BlockCacheFactory unchanged in this ticket.
> * Use the new factory helpers in tests or integration code that needs
> CacheAccessService but still constructs legacy BlockCache implementations
> directly.
> Example API shape:
> {code:java}
> CacheAccessService service =
> CacheAccessServices.fromBlockCache(blockCache);
> CacheAccessService service =
> CacheAccessServices.fromBlockCache(optionalBlockCache);
> {code}
> This preserves the current compatibility model:
> {noformat}
> Legacy cache implementation
> -> BlockCache
> -> BlockCacheBackedCacheAccessService
> -> CacheAccessService
> {noformat}
> This ticket is a bridge step. A later factory-wiring ticket can make
> BlockCacheFactory or a new cache factory assemble CacheAccessService,
> CacheTopology, and CacheEngine implementations directly. This ticket should
> only provide the missing factory helpers needed during the compatibility
> migration.
> Out of scope:
> * Do not refactor BlockCacheFactory.
> * Do not replace direct constructors of LruBlockCache, LruAdaptiveBlockCache,
> TinyLfuBlockCache, or BucketCache.
> * Do not migrate implementation-specific cache tests away from concrete cache
> classes.
> * Do not introduce CacheEngine adapters in this ticket.
> * Do not change cache read/write semantics.
> Acceptance criteria:
> * CacheAccessServices can create a CacheAccessService from a non-null
> BlockCache.
> * CacheAccessServices can create a CacheAccessService from
> Optional<BlockCache>.
> * Optional.empty() maps to the disabled/no-op CacheAccessService.
> * Null inputs are rejected consistently.
> * Unit tests cover the new factory helpers.
> * Existing BlockCache-backed behavior remains unchanged.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
