[jira] [Created] (HBASE-30205) Add CacheAccessService factory helpers for legacy BlockCache-backed implementations

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

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)