Hi Walter,
A searcher has an immutable (stale) view of the index of when it was
created. Therefore, a soft commit always open a new searcher, because this
new searcher will reflect the changes in the index since the last commit.
When you are doing a hard commit you have the option of not opening t
Thanks. I don’t need openSearcher=false on soft commits. I was just musing
about it. Keeping the same query result cache would be very similar to using an
HTTP cache in front of Solr. Which means that it should be done with an HTTP
cache, because those are straighforward and very fast.
It would
On 11/16/2018 12:21 PM, Shawn Heisey wrote:
On 11/16/2018 11:54 AM, Walter Underwood wrote:
I’ve been reading all the documentation and articles I can find, and
they all say that soft commit makes documents visible for searching.
They don’t specifically say that they invalidate the caches and/o
On 11/16/2018 11:54 AM, Walter Underwood wrote:
Does a soft commit always open a new Searcher?
In general, yes. To quote the oft-referenced blog post ... hard commits
are about durability, soft commits are about visibility.
I actually don't know if "openSearcher=false" would work on a soft
Does a soft commit always open a new Searcher?
I’ve been reading all the documentation and articles I can find, and they all
say that soft commit makes documents visible for searching. They don’t
specifically say that they invalidate the caches and/or open a new Searcher. I
guess I can see a us
