Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-16654

Add support for node-level caches



    • New Feature
    • Status: Closed
    • Minor
    • Resolution: Fixed
    • main (10.0)
    • 9.4
    • None
    • None


      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:

      1. 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.
      2. 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:

      1. "thin" core-level caches (filterCache, queryResultCache, etc.) backed by "node-level" caches.
      2. 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.


        Issue Links



              Unassigned Unassigned
              magibney Michael Gibney
              0 Vote for this issue
              5 Start watching this issue



                Time Tracking

                  Original Estimate - Not Specified
                  Not Specified
                  Remaining Estimate - 0h
                  Time Spent - 4h 20m
                  4h 20m