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)