[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851733#comment-17851733 ] Michael Gibney commented on SOLR-16654: --- Thanks for the heads-up. I dug into this a bit, and it looks like it's actually quite difficult to come up with concrete expectations regarding the exact entries that will be warmed and/or evicted. I'll re-work this test accordingly (testing for expectations that _can_ reliably be met) and push a fix. > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17850547#comment-17850547 ] David Smiley commented on SOLR-16654: - [~magibney] the test has been failing about 0.5% of the time since when this was committed: [http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestThinCache.testSimple] (we can't re-open this because it shipped but can just post a JIRA-less PR) > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763551#comment-17763551 ] ASF subversion and git services commented on SOLR-16654: Commit 0195da19f323047c9dfbcb760f52439c9f1a6c75 in solr's branch refs/heads/branch_9x from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=0195da19f32 ] SOLR-16654: Improve test (#1886) * remove 2 test config files * revert "solr.tests.loadSolrXml" option recently added * use EmbeddedSolrServerTestRule for initialization > 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 > Time Spent: 4h > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17763548#comment-17763548 ] ASF subversion and git services commented on SOLR-16654: Commit b614c1fa02ac9f34144a0d0239edfc66a7700c01 in solr's branch refs/heads/main from David Smiley [ https://gitbox.apache.org/repos/asf?p=solr.git;h=b614c1fa02a ] SOLR-16654: Improve test (#1886) * remove 2 test config files * revert "solr.tests.loadSolrXml" option recently added * use EmbeddedSolrServerTestRule for initialization > 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 > Time Spent: 4h > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760617#comment-17760617 ] ASF subversion and git services commented on SOLR-16654: Commit 58c8dfc94a974664d6a80a3410a5ebaef6f1201b in solr's branch refs/heads/branch_9x from Michael Gibney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=58c8dfc94a9 ] SOLR-16654: Add support for node-level caches (#1351) (cherry picked from commit 22ac9105ea0382215c8fe558fc55977dc98aa14c) > 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 > Time Spent: 3.5h > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17760615#comment-17760615 ] ASF subversion and git services commented on SOLR-16654: Commit 22ac9105ea0382215c8fe558fc55977dc98aa14c in solr's branch refs/heads/main from Michael Gibney [ https://gitbox.apache.org/repos/asf?p=solr.git;h=22ac9105ea0 ] SOLR-16654: Add support for node-level caches (#1351) > 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 > Time Spent: 3.5h > 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 {{}} 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
[jira] [Commented] (SOLR-16654) Add support for node-level caches
[ https://issues.apache.org/jira/browse/SOLR-16654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 {{}} 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