Thanks a lot Shawn for an exhaustive reply! Regards, Dmitry
On Tue, Oct 1, 2013 at 5:37 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 10/1/2013 2:48 AM, Dmitry Kan wrote: > > This is a minor thing, perhaps, but thought to ask / share: > > > > if there are no modifications to an index and a softCommit or hardCommit > > issued, then solr flushes the cache. > > Any time you do a commit that opens a new Searcher object > (openSearcher=true, which is required if you want index changes to be > visible to people making queries), the caches are invalidated. This is > because the layout of the index (and therefore the Lucene internal IDs) > can completely change with *any* commit/merge, and there is no easy and > reliable way to determine when the those numbers have NOT changed. > > If you have warming queries configured, those happen on the new > searcher, populating the new cache. If you have cache autoWarming > configured, then keys from the old caches are re-queried against the new > index and used to populate the new cache. > > I do not understand deep Lucene internals, but what I've seen come > through Jira activity and commits over the last year or two has been a > strong move towards per-segment thinking instead of whole-index > thinking. If this idea becomes applicable to all aspects of Lucene, > then perhaps Solr caches can also become per-segment, and will not need > to be completely invalidated except in the case of a major merge or > forceMerge. > > Thanks, > Shawn > >
