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
