[jira] [Created] (HBASE-30196) Add diagnostic cached-block iteration capability for pluggable cache engines

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

Vladimir Rodionov created HBASE-30196:
-----------------------------------------

             Summary: Add diagnostic cached-block iteration capability for pluggable cache engines
                 Key: HBASE-30196
                 URL: https://issues.apache.org/jira/browse/HBASE-30196
             Project: HBase
          Issue Type: New Feature
          Components: BlockCache
            Reporter: Vladimir Rodionov
            Assignee: Vladimir Rodionov
             Fix For: 4.0.0-alpha-1


Add diagnostic cached-block iteration capability for pluggable cache engines

The current BlockCache API extends/uses iteration over CachedBlock metadata. This is used mostly by tests and by at least one diagnostic JSP/admin page.

As the block cache architecture moves toward CacheAccessService, CacheTopology, and CacheEngine, we should not add iterator() directly to CacheAccessService. CacheAccessService is intended to be the read/write path facade for block lookup, insertion, invalidation, and lifecycle operations. Cached-block enumeration is diagnostic/admin functionality and may be relatively expensive or implementation-specific.

However, diagnostics and tests still need a cache-implementation-independent way to enumerate cached block metadata. New pluggable cache engines should be able to expose cached block information without requiring callers to depend on the legacy BlockCache interface.

Proposed approach:

* Add an optional diagnostic capability interface, for example CacheBlockIterable or CacheBlockIterableEngine.
* The interface should expose an Iterator<CachedBlock> or equivalent cached-block metadata iterator.
* Cache engines that support diagnostic enumeration can implement this capability.
* Engines that cannot or should not expose cached block enumeration are not required to implement it.
* CacheTopology can provide a helper to aggregate iteration across engines that support this capability.
* Existing BlockCache-based implementations can be adapted by delegating to the current BlockCache iterator().
* Tests and diagnostic JSP/admin code can later migrate from BlockCache.iterator() to this new diagnostic capability.

This keeps CacheAccessService focused on hot-path cache access while still allowing diagnostics, tests, and admin pages to work with future pluggable cache implementations.

Out of scope:

* Do not add iterator() to CacheAccessService.
* Do not require every CacheEngine implementation to support enumeration.
* Do not change cache read/write semantics.
* Do not migrate unrelated BlockCache users in this ticket unless they are directly related to cached-block diagnostics.

Acceptance criteria:

* A new optional cached-block iteration capability is added under the cache package.
* Existing BlockCache-backed implementation can expose this capability through an adapter or engine wrapper.
* Topology-level code can discover and/or aggregate iterable engines.
* Tests cover supported and unsupported iteration cases.
* Diagnostic/test callers have a path to migrate away from direct BlockCache.iterator() usage.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)