[
https://issues.apache.org/jira/browse/HBASE-30206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov reassigned HBASE-30206:
-----------------------------------------
Assignee: Vladimir Rodionov
> Add test factory helpers for CacheAccessService-backed cache instances
> ----------------------------------------------------------------------
>
> Key: HBASE-30206
> URL: https://issues.apache.org/jira/browse/HBASE-30206
> Project: HBase
> Issue Type: New Feature
> Components: BlockCache
> Affects Versions: 4.0.0-alpha-1
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
>
> As the block cache architecture migrates from direct BlockCache usage toward
> CacheAccessService, many tests still directly instantiate concrete BlockCache
> implementations such as LruBlockCache, LruAdaptiveBlockCache,
> TinyLfuBlockCache, and BucketCache.
> Some of these direct constructors are appropriate because the tests verify
> implementation-specific cache behavior. However, many integration-style tests
> only need "a cache" for exercising HFile, CacheConfig, reader, writer,
> prefetch, or compaction behavior. Those tests should be able to use
> CacheAccessService without manually constructing a BlockCache, wrapping it,
> or building a large Configuration object for every case.
> Currently, replacing a single direct constructor call with CacheAccessService
> setup can add unnecessary boilerplate. To make migration practical and
> readable, we should add test-only factory helpers that mirror the common
> existing cache constructors and return CacheAccessService instances.
> Proposed approach:
> * Add test utility factory methods for creating CacheAccessService instances
> backed by existing cache implementations.
> * The helper methods should accept the same or very similar arguments as
> common existing cache constructors.
> * Internally, these helpers may instantiate the legacy BlockCache
> implementation and wrap it using CacheAccessServices.fromBlockCache(...).
> * Provide variants that return only CacheAccessService for integration-style
> tests.
> * Provide holder/instance variants for tests that need both the concrete
> BlockCache and the CacheAccessService facade.
> * Keep concrete implementation tests free to use direct constructors where
> they are testing cache-specific internals.
> Example API shape:
> {code:java}
> CacheAccessService cache =
> CacheAccessServiceTestFactory.lru(maxSize, blockSize, evictionThread, conf);
> CacheAccessService cache =
> CacheAccessServiceTestFactory.bucket(conf);
> CacheAccessServiceTestInstance<LruBlockCache> cache =
> CacheAccessServiceTestFactory.lruInstance(maxSize, blockSize,
> evictionThread, conf);
> CacheAccessService service = cache.service();
> LruBlockCache lru = cache.blockCache();
> {code}
> This gives tests a concise migration path:
> {noformat}
> Before:
> new LruBlockCache(...)
> After:
> CacheAccessServiceTestFactory.lru(...)
> {noformat}
> The implementation can initially remain legacy-backed:
> {noformat}
> test factory
> -> concrete BlockCache constructor
> -> CacheAccessServices.fromBlockCache(...)
> -> CacheAccessService
> {noformat}
> Later, when CacheEngine and topology-backed implementations are available,
> the test factory can be changed internally without rewriting all integration
> tests again.
> Out of scope:
> * Do not remove all direct concrete cache constructors from tests in this
> ticket.
> * Do not change production cache construction.
> * Do not refactor BlockCacheFactory.
> * Do not require implementation-specific tests to use CacheAccessService.
> * Do not introduce new cache engines in this ticket.
> * Do not change cache read/write semantics.
> Acceptance criteria:
> * Test-only factory helpers exist for common legacy cache implementations.
> * Factory helpers can create CacheAccessService instances backed by
> LruBlockCache, LruAdaptiveBlockCache, TinyLfuBlockCache, and BucketCache
> where practical.
> * A holder/instance helper exists for tests that need both the concrete cache
> and the CacheAccessService facade.
> * Null inputs are rejected consistently.
> * Unit tests cover the new test factory helpers.
> * At least a small number of integration-style tests are migrated to use the
> new helpers as examples.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
