NMS-19537: Reworked Interpolator to create Scope on demand

[christianpape]

• JIRA: https://opennms.atlassian.net/browse/NMS-19537

[Copilot]

Pull request overview

Adds a ConfigAdmin-tunable cache wrapper around the MATE EntityScopeProvider and wires it into thresholding so metadata lookups can be reused rather than repeatedly fetched.

Changes:

• Introduces CachedEntityScopeProvider backed by Guava LoadingCache with configurable expiry/refresh/size.
• Updates threshd blueprint wiring to wrap EntityScopeProviderImpl with the cached provider and add ConfigAdmin defaults.
• Adds an integration test subclass intended to run existing scope-provider ITs against the cached wrapper.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
features/collection/thresholding/impl/src/main/resources/OSGI-INF/blueprint/blueprint.xml	Adds ConfigAdmin properties + wires DefaultThresholdingSetPersister to use a cached scope provider.
core/mate/model/src/test/java/org/opennms/core/mate/model/EntityScopeProviderIT.java	Makes injected fields protected to allow reuse in a subclass IT.
core/mate/model/src/test/java/org/opennms/core/mate/model/CachedEntityScopeProviderIT.java	New IT subclass that wraps the provider with the cache.
core/mate/model/src/main/java/org/opennms/core/mate/model/CachedEntityScopeProvider.java	New cached EntityScopeProvider implementation using Guava caches.
core/mate/model/pom.xml	Adds an explicit Guava dependency for the new caching implementation.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[indigo423]

Just thinking out loud. The Metadata interpolation happens also in the service monitoring framework in Pollderd and has a similar characteristic. Would we have to re-implement a similar cache there as well?

The generic question that comes out of this. Do we have to implement such a cache in any hot path for daemons where we poll large data endpoint or additional latency reduces our monitoring throughput (e.g. SNMP Interface Poller, Enlinkd, Pollerd, Collectd and Provisiond)?

There might be others where want to use Metadata in the future.

[christianpape]

Just thinking out loud. The Metadata interpolation happens also in the service monitoring framework in Pollderd and has a similar characteristic. Would we have to re-implement a similar cache there as well?

The generic question that comes out of this. Do we have to implement such a cache in any hot path for daemons where we poll large data endpoint or additional latency reduces our monitoring throughput (e.g. SNMP Interface Poller, Enlinkd, Pollerd, Collectd and Provisiond)?

There might be others where want to use Metadata in the future.

It's just wiring in another implementation. This will be easy as long as we know that this cache really solves the problem.

[cgorantla]

It would be good to separate ScopeProvider changes from the cache changes.

Also we should avoid reordering imports for easier diff

[christianpape]

It would be good to separate ScopeProvider changes from the cache changes.

Also we should avoid reordering imports for easier diff

Cache is moved to issue NMS-19573 and PR #8331.