On Mon, Apr 18, 2016 at 8:02 PM, Erick Erickson wrote:
> This is about real-time get.
To clarify, it's used to handle real-time get type functionality in
general. It's used internally in a couple ways, not just when a user
issues a "real-time get".
-Yonik
Hi Erick,
Thanks for the info. Was under impression that we have extra setting
"openSearcher" to control when the searchers are being opened.
>From what you saying a searcher can be opened not only as a result of
hard or soft commit.
What I am observe, to follow your example:
T0 - everything is
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
wrote:
> This is ab
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 docume
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
