On 9/24/2015 3:11 PM, Jeff Wartes wrote:
> Answering my own question: Looks like the default filterCache regenerator
> uses the old cache to re-executes queries in the context of the new
> searcher and does nothing with the old cache value.
>
> So, the new searcher’s cache contents will be
If I configure my filterCache like this:
and I have <= 10 distinct filter queries I ever use, does that mean I’ve
effectively disabled cache invalidation? So my cached filter query results
will never change? (short of JVM restart)
I’m unclear on whether autowarm simply copies the value into
Answering my own question: Looks like the default filterCache regenerator
uses the old cache to re-executes queries in the context of the new
searcher and does nothing with the old cache value.
So, the new searcher’s cache contents will be consistent with that
searcher’s view, regardless of
Jeff:
Yes, exactly. Otherwise the autowarming would be quite useless since
what's stored in the cache is the _lucene_ doc ID (either as a bitmap
or as a list of IDs). And the lucene doc ID can change when merging,
so the old IDs are useless.
Best,
Erick
On Thu, Sep 24, 2015 at 2:11 PM, Jeff
