VladRodionov opened a new pull request, #8522:
URL: https://github.com/apache/hbase/pull/8522
### Summary
This PR replaces `CombinedBlockCache` as the primary `CacheAccessService`
orchestration path for combined L1/L2 block cache access.
The previous compatibility path exposed a `CombinedBlockCache` through
`BlockCacheBackedCacheAccessService`. With the topology-backed cache
architecture in place, the combined cache path can now be represented as:
```text
CacheAccessService
-> TopologyBackedCacheAccessService
-> TieredExclusiveTopology
-> BlockCacheBackedCacheEngine(L1)
-> BlockCacheBackedCacheEngine(L2)
```
`CombinedBlockCache` is not removed in this PR. It remains available as a
legacy `BlockCache` object and for code paths that still depend on the old API.
This PR moves the migration-facing cache access path to
`TopologyBackedCacheAccessService`.
### Changes
* Updates `CacheAccessServices.fromBlockCache(...)` so `CombinedBlockCache`
is exposed as a topology-backed `CacheAccessService`.
* Uses `TopologyBackedCacheAccessServices.fromCombinedBlockCache(...)` to
extract L1/L2 caches from `CombinedBlockCache` and assemble a
`TieredExclusiveTopology`.
* Preserves regular `BlockCache` behavior by continuing to use
`BlockCacheBackedCacheAccessService` for non-combined caches.
* Extends topology-backed compatibility behavior needed by existing HFile
and data-tiering paths, including:
* combined-cache detection through the active cache service;
* `shouldCacheFile(...)`;
* `shouldCacheBlock(...)`;
* fully cached file visibility;
* file caching completion notification propagation.
* Updates tests to validate the topology-backed combined-cache path.
### Why this is needed
The pluggable block cache architecture is moving from implicit orchestration
inside `CombinedBlockCache` toward explicit cache topology.
Legacy path:
```text
LruBlockCache + BucketCache
-> CombinedBlockCache
-> BlockCacheBackedCacheAccessService
```
New path:
```text
LruBlockCache + BucketCache
-> BlockCacheBackedCacheEngine
-> TieredExclusiveTopology
-> TopologyBackedCacheAccessService
```
This is the next migration step after:
* HBASE-30024, which added `BlockCacheBackedCacheEngine`
* HBASE-30025, which added the helper for constructing a topology-backed
combined-cache service
### Compatibility notes
This PR does not remove `CombinedBlockCache`.
Existing concrete caches such as `LruBlockCache` and `BucketCache` still
implement `BlockCache`. They are adapted to `CacheEngine` through
`BlockCacheBackedCacheEngine`.
The goal is to move orchestration to the topology-backed access path while
keeping existing cache implementations and legacy APIs intact.
### Out of scope
* No removal of `CombinedBlockCache`.
* No direct migration of `LruBlockCache`, `BucketCache`,
`TinyLfuBlockCache`, or `LruAdaptiveBlockCache` to implement `CacheEngine`.
* No removal of `BlockCacheBackedCacheAccessService`.
* No JSP/admin diagnostics cleanup.
* No broad metrics refactoring.
* No intended change to cache placement or eviction behavior.
### Testing
Ran:
```bash
mvn -pl hbase-server -DskipTests compile
mvn -pl hbase-server -Dtest=TestHFile test
mvn -pl hbase-server -Dtest=TestDataTieringManager test
mvn -pl hbase-server -Dtest=TestCacheAccessServices test
mvn -pl hbase-server -Dtest=TestTopologyBackedCacheAccessServices test
mvn -pl hbase-server \
-Dtest=TestCombinedBlockCacheCompatibleTopologyBackedCacheAccessService
test
mvn -pl hbase-server spotless:check
mvn -pl hbase-server checkstyle:check
```
### AI assistance disclosure
This PR was prepared with assistance from ChatGPT. All changes were
reviewed, tested, and submitted by the author.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
