[
https://issues.apache.org/jira/browse/HBASE-30196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
ASF GitHub Bot updated HBASE-30196:
-----------------------------------
Labels: pull-request-available (was: )
> 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
> Priority: Major
> Labels: pull-request-available
> 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)
