Vladimir Rodionov created HBASE-30205:
-----------------------------------------
Summary: 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
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)
