[ 
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

Reply via email to