markhoerth opened a new issue, #11128:
URL: https://github.com/apache/gravitino/issues/11128
### Version
main branch
### Describe what's wrong
Summary
When the IRC service runs with iceberg.config-provider.impl =
dynamic-config-provider (required when authorization is enabled, enforced at
IcebergCatalogWrapperManager.createCatalogWrapper:113), server-level
table-metadata-cache-* properties in gravitino.conf have no effect. The
settings are parsed at startup and visible in the boot log, but they never
reach the per-catalog IcebergConfig used to construct IcebergCatalogWrapper.
The wrapper falls back to TableMetadataCache.DUMMY (a no-op cache) regardless
of what the server-level config specifies.
No warning, log line, or exception indicates that the configuration was
ignored. Operators following the documentation see cache settings in the
startup log and reasonably assume the cache is active.
Affects 100% of authorization-enabled deployments.
Affected configuration
Server-level keys that are silently dropped on the dynamic path:
gravitino.iceberg-rest.table-metadata-cache-impl=org.apache.gravitino.iceberg.service.metadatacache.LocalTableMetadataCache
gravitino.iceberg-rest.table-metadata-cache-cache-max-size=1000
gravitino.iceberg-rest.table-metadata-cache-cache-expire-after-access-ms=3600000
The same keys at the catalog property level work correctly.
Code path
IcebergCatalogWrapperManager.createCatalogWrapper:113 selects the dynamic
provider when authorization is enabled.
DynamicIcebergConfigProvider.getIcebergCatalogConfig:76 is the entry point
for per-catalog config.
DynamicIcebergConfigProvider.getIcebergConfigFromCatalogProperties:103
invokes the translator.
DynamicIcebergConfigProvider.getIcebergConfigFromCatalogProperties:153 is a
pure translator over catalog.properties(). Server-level config is never merged
in.
IcebergCatalogWrapper.loadTableMetadataCache:391 receives an IcebergConfig
without cache settings.
IcebergCatalogWrapper.loadTableMetadataCache:394 returns
TableMetadataCache.DUMMY.
For comparison, StaticIcebergConfigProvider reads the same server-level keys
and produces a working cache configuration. The bug is specific to the dynamic
path.
Steps to reproduce
Deploy Gravitino with authorization enabled (forces dynamic-config-provider).
Set
gravitino.iceberg-rest.table-metadata-cache-impl=org.apache.gravitino.iceberg.service.metadatacache.LocalTableMetadataCache
and related cache properties in gravitino.conf.
Start Gravitino. Confirm the cache properties appear in the startup log
(AuxService name:iceberg-rest, config:{...table-metadata-cache-impl=...}).
Create a catalog with a small number of tables.
Drive GET /tables/{name} requests against the IRC endpoint for one of the
tables in a tight loop.
Search Gravitino logs: zero references to LocalTableMetadataCache. Cache
initialization is never logged because the cache is never constructed.
As a control: set the same cache properties at the catalog level via the
setProperty API. The next IRC request emits LocalTableMetadataCache
initialized... and subsequent reads are cached.
Expected behavior
Server-level table-metadata-cache-* settings should propagate to the
per-catalog IcebergConfig on the dynamic-config-provider path, in the same way
they do on the static path. Catalog-level properties should override
server-level defaults to remain consistent with how Gravitino layers
configuration elsewhere.
Actual behavior
Server-level cache settings are silently dropped. Every catalog uses
TableMetadataCache.DUMMY unless the operator sets the same cache properties on
every catalog individually at creation time.
Workaround
Set the cache properties at the catalog level via setProperty. Verified end
to end: the catalog property listener at IcebergCatalogWrapperManager:73-82
invalidates and rebuilds the wrapper, and the next IRC request initializes a
working cache.
Per-catalog configuration is workable but not a fix. Catalogs in production
environments are created by self-service portals, programmatic provisioning,
and Terraform, all of which would need to be updated independently to set cache
properties on every catalog at creation time.
### Error message and/or stacktrace
NA
### How to reproduce
NA
### Additional context
_No response_
--
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]
