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