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 the searcher because you may be doing a bulk loading operation, for example, therefore you don't need to pay the costs of opening a new searcher.
Em sex, 16 de nov de 2018 17:54, Walter Underwood <wun...@wunderwood.org escreveu: > > 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 be great if the documentation explicitly said that soft commits open a new Searcher. That would parallel the discussion under hard commits. > > wunder > Walter Underwood > wun...@wunderwood.org > http://observer.wunderwood.org/ (my blog) > > > On Nov 16, 2018, at 11:21 AM, Shawn Heisey <apa...@elyograg.org> wrote: > > > > 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 commit, but even if it does (and prevents opening a new searcher), it's not a particularly useful option for soft commit.That combination goes against the entire reason that soft commit exists. > > > > For hard commit, setting openSearcher=false does make sense -- firing that commit is usually very fast, and the desired outcome is a side effect -- starting a new transaction log. > > > >> 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 use case where it would be OK for the caches to have stale information for a while, but uncached searches would find the new documents. And invalidating individual entries in the document cache might be doable. > > > > The only way you'll see changes is by opening a new searcher. The existing searcher will not query the new index state. When a new searcher is opened, it has its own cache instances, and those instances are empty. As you might already know, autowarming reaches into the old searcher's caches and uses the queries it finds there to warm the new caches. > > > > Thanks, > > Shawn > >
