[
https://issues.apache.org/jira/browse/HBASE-30383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Rodionov updated HBASE-30383:
--------------------------------------
Hadoop Flags: Reviewed
Release Note:
This change is intended to preserve cache behavior, but it includes two
externally visible compatibility changes that should be called out when the
work is merged to master:
- `HBaseTestingUtility` test helper methods that previously accepted
`BlockCache`, including
`createRegionAndWAL(...)` and `createTestRegion(...)`, now accept
`CacheAccessService`.
`HBaseTestingUtility` is deprecated but is still `@InterfaceAudience.Public`,
so this is a source
compatibility change for downstream test code using these methods. I
intentionally did not retain
`BlockCache` compatibility overloads because the goal of the cache migration
is to remove
`BlockCache` dependencies completely.
- `blockCacheView.jsp` now returns
`Content-Type: application/json;charset=UTF-8` instead of
`text/html;charset=UTF-8`. The endpoint already returns JSON, so the new
content type reflects the
actual response format. This does not change the JSON payload, but clients
that inspect the HTTP
content type will observe the change.
Except for the compatibility points above, the changes in this PR are intended
to preserve existing
user-visible cache behavior while migrating implementation and call sites to
the pluggable cache
APIs.
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Migrate RegionServer block cache ownership to CacheAccessService
> ----------------------------------------------------------------
>
> Key: HBASE-30383
> URL: https://issues.apache.org/jira/browse/HBASE-30383
> Project: HBase
> Issue Type: New Feature
> Reporter: Vladimir Rodionov
> Assignee: Vladimir Rodionov
> Priority: Major
> Labels: pull-request-available
> Fix For: 4.0.0-alpha-1
>
>
> Migrate the RegionServer runtime from owning and exposing a legacy BlockCache
> to using CacheAccessService as the primary block-cache access abstraction.
> Currently, HRegionServer creates the block cache through
> BlockCacheFactory.createBlockCache() and stores it as a BlockCache. This
> keeps the production RegionServer path tied to legacy implementations such as
> LruBlockCache, CombinedBlockCache, and InclusiveCombinedBlockCache, even
> though the new cache architecture supports native CacheEngine implementations
> and explicit CacheTopology implementations.
> HRegionServer should instead construct and own a CacheAccessService using the
> new configuration-based construction path. This allows native CacheEngine
> implementations, such as LruCacheEngine, to be used directly without first
> constructing a BlockCache and adapting it through BlockCacheBackedCacheEngine.
> The migration should propagate CacheAccessService through
> RegionServerServices, HRegion, and HStore so that CacheConfig is constructed
> using CacheAccessService rather than BlockCache.
> The current RegionServer cache ownership path is approximately:
> {code:java}
> HRegionServer
> |
> +-- BlockCacheFactory.createBlockCache()
> |
> +-- BlockCache
> |
> +-- LruBlockCache
> |
> +-- CombinedBlockCache
> |
> +-- L1
> +-- L2
> {code}
> The target path should be:
> {code:java}
> Configuration
> |
> v
> CacheAccessServices.fromConfiguration(...)
> |
> v
> CacheEngine(s)
> |
> v
> CacheTopology
> |
> v
> CacheAccessService
> |
> +-- HRegion
> |
> v
> HStore
> |
> v
> CacheConfig
> {code}
> For the LRU policy, the production RegionServer path should use
> LruCacheEngine directly rather than:
> {code:java}
> LruBlockCache
> -> BlockCacheBackedCacheEngine
> {code}
> The existing RegionServerServices.getBlockCache() API and other legacy
> BlockCache consumers may be retained temporarily where required for
> compatibility. However, the migration must not require constructing a
> duplicate legacy BlockCache alongside the new CacheAccessService.
> The migration should also address RegionServer operations that currently
> access BlockCache directly, including cache shutdown, HFile eviction,
> metrics/reporting, and graceful-stop cache handling.
> Capabilities that require additional abstractions, such as dynamic L1
> resizing by HeapMemoryManager, may be migrated separately.
> Scope:
>
> * Make CacheAccessService the primary block-cache object owned by
> HRegionServer.
> * Construct the service through CacheAccessServices.fromConfiguration(...).
> * Add CacheAccessService access to RegionServerServices.
> * Propagate CacheAccessService from HRegionServer to HRegion.
> * Update HStore to construct CacheConfig using CacheAccessService.
> * Migrate direct RegionServer cache operations such as shutdown and HFile
> eviction to CacheAccessService.
> * Update cache metrics/reporting where the required information is already
> exposed by the new cache abstractions.
> * Remove the production data-path dependency on
> BlockCacheFactory.createBlockCache().
> * Preserve legacy compatibility APIs where necessary during migration.
> * Do not construct a second legacy BlockCache solely to support compatibility
> consumers.
> Out of Scope:
> * Dynamic cache resizing performed by HeapMemoryManager. This may require a
> native CacheEngine capability analogous to ResizableBlockCache.
> * Configuration-change propagation through CacheAccessService. This is
> handled separately.
> * Migration of remaining legacy BlockCache implementations to native
> CacheEngine implementations.
> Acceptance Criteria:
> * HRegionServer owns and uses CacheAccessService as its primary block-cache
> abstraction.
> * HRegion and HStore receive cache access through CacheAccessService.
> * CacheConfig used by the RegionServer data path is constructed using
> CacheAccessService.
> * LRU configuration results in the production RegionServer using
> LruCacheEngine directly.
> * LruBlockCache is not created merely to provide a BlockCache compatibility
> object for the native LruCacheEngine.
> * No duplicate cache instances are created during the migration.
> * Existing RegionServer, HRegion, HStore, and HFile cache behavior remains
> compatible.
> * Existing relevant tests continue to pass.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
