Thanks Shalin, that was very helpfull.
On 09/20/2017 01:02 PM, Shalin Shekhar Mangar wrote:
That log shows that the searcher being opened is the "realtime"
searcher as opposed to the "main" searcher. The realtime searcher is
quite lightweight. It causes a flush of built index segments from the
m
That log shows that the searcher being opened is the "realtime"
searcher as opposed to the "main" searcher. The realtime searcher is
quite lightweight. It causes a flush of built index segments from the
memory to the disk and opens a new searcher over them. No autowarming
or fsync happens for realt
Hi Erick
Thanks for your response. I understand your point, but what I was asking
was does solr reopen searchers after a commit call even if the commit
was called with openSearcher=false since this is what seems to be
happening based on these log entries?
Also, it seems that if autocommit is
First, I would not recommend you call commit from the client. It's
usually far better to let your autocommit settings in solrconfig.xml
deal with it. When you need to search, you either need to configure
with true
or set to something other than -1.
https://lucidworks.com/2013/08/23/understandin
Hi eveyone
I am trying to figure out why calling commit from my client takes a very
long time in an environment with concurrent updates, and I see the
following snippet in the solr log files when client calls for commit. my
question is regarding the third info. what is it opening? and how can