Erick can correct me. I think "searcher" here might just sound a bit misleading. Real time get is really about fetching by id, not issuing searches per-se. Only after a soft or hard commit does a document truly become searchable.
On Mon, Apr 18, 2016 at 8:02 PM Erick Erickson <erickerick...@gmail.com> wrote: > This is about real-time get. The idea is this. Suppose > you have a doc doc1 already in your index at time T1 > and update it at time T2 and your soft commit happens > at time T3. > > If a search a search happens between time T1 and T2 > but the fetch happens between T2 and T3, you get > back the updated document, not the doc that was in > the index. So the reatime get is outside the > soft and hard commit issues. > > It's a pretty lightweight operation, no caches are invalidated > or warmed etc. > > Best, > Erick > > On Mon, Apr 18, 2016 at 9:59 AM, Jaroslaw Rozanski > <s...@jarekrozanski.com> wrote: > > Hi, > > > > What exactly triggers opening new "realtime" searcher? > > > > 2016-04-18_16:28:02.33289 INFO (qtp1038620625-13) [c:col1 s:shard1 > r:core_node3 x:col1_shard1_replica3] o.a.s.s.SolrIndexSearcher Opening > Searcher@752e986f[col1_shard1_replica3] realtime > > > > I am seeing above being triggered when adding documents to index. The > > frequency (from few milliseconds to few seconds) does not correlate with > > maxTime of either autoCommit or autoSoftCommit (which are fixed to tens > > of seconds). > > > > Client never sends commit message explicitly (and there is > > IgnoreCommitOptimizeUpdateProcessorFactory in processor chain). > > > > Re: Solr 5.5.0 > > > > > > > > Thanks, > > Jarek > > >
