lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shawn Heisey <>
Subject Re: {soft}Commit and cache flusing
Date Tue, 01 Oct 2013 14:37:21 GMT
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


View raw message