[
https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Gibney resolved SOLR-16654.
-----------------------------------
Fix Version/s: 9.4
Resolution: Fixed
> Add support for node-level caches
> ---------------------------------
>
> Key: SOLR-16654
> URL: https://issues.apache.org/jira/browse/SOLR-16654
> Project: Solr
> Issue Type: New Feature
> Affects Versions: main (10.0)
> Reporter: Michael Gibney
> Priority: Minor
> Fix For: 9.4
>
> Time Spent: 4h 20m
> Remaining Estimate: 0h
>
> 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: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
