[
https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17687308#comment-17687308
]
Michael Gibney commented on SOLR-16654:
---------------------------------------
[PR #1351|https://github.com/apache/solr/pull/1351] is broken into three
initial commits; the last of these commits offers a proof-of-concept/reference
implementation of a "thin cache" backed by a node level cache. This "ThinCache"
implementation is intended in its current state mainly for example/demo
purposes. ramBytes accounting and testing would need to be built out.
There is discussion of related use cases under "Story 1" of
[SIP-4|https://cwiki.apache.org/confluence/display/SOLR/SIP-4+Resource+management+framework]
(see also SOLR-13578).
> 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
> Priority: Minor
> Time Spent: 10m
> 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: [email protected]
For additional commands, e-mail: [email protected]
