Michael Gibney created SOLR-16654:
-------------------------------------
Summary: Add support for node-level caches
Key: SOLR-16654
URL: https://issues.apache.org/jira/browse/SOLR-16654
Project: Solr
Issue Type: New Feature
Security Level: Public (Default Security Level. Issues are Public)
Affects Versions: main (10.0)
Reporter: Michael Gibney
Caches are currently configured only at the level of individual cores, sized
according to expected usage patterns for the core.
The main tradeoff in cache sizing is heap space, which is of course limited at
the JVM/node level. Thus there is a conflict between sizing cache to per-core
use patterns vs. sizing cache to enforce limits on overall heap usage.
This issue proposes some minor changes to facilitate the introduction of
node-level caches:
# support a {{<caches/>}} node in {{solr.xml}}, to parse named cache configs,
for caches to be instantiated/accessible at the level of {{CoreContainer}}. The
syntax of this config node would be identical to the syntax of the "user
caches" config in {{solrconfig.xml}}.
# provide a hook in searcher warming to initialize core-level caches with the
initial associated searcher. (analogous to {{warm()}}, but for the initial
searcher -- see SOLR-16017, which fwiw was initially opened to support a
different use case that requires identical functionality).
Part of the appeal of this approach is that the above (minimal) changes are the
only changes required to enable pluggable node-level cache implementations --
i.e. no further API changes are necessary, and no behavioral changes are
introduced for existing code.
Note: I anticipate that the functionality enabled by nodel-level caches will
mainly be useful for enforcing global resource limits -- it is not primarily
expected to be used for sharing entries across different cores/searchers
(although such use would be possible).
Initial use cases envisioned:
# "thin" core-level caches (filterCache, queryResultCache, etc.) backed by
"node-level" caches.
# dynamic (i.e. not static-"firstSeacher") warming of OrdinalMaps, by placing
OrdinalMaps in an actual cache with, e.g., a time-based expiration policy.
This functionality would be particularly useful for cases with many cores per
node, and even more so in cases with uneven core usage patterns. But having the
ability to configure resource limits at a level that directly corresponds to
the available resources (i.e., node-level) would be generally useful for all
cases.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
