Thanks for following up the question on IRC! All right, your explanation makes it more clear, and now the words "until the *first searcher* is done warming" stand out.
Yes, I have noticed commits in a quick succession (related to the other question on stamping core names on log entries I asked). They certainly gave Solr hard time warming up the searchers. Since we use master-only shards setup (i.e. no slaves), we have increased the maxWarmingSearchers to 5 and have not yet seen the issue. Btw, related to master-slave setup. What makes read-only slave not to come across the same issue? Would it not pull data from the master and warm up searchers? Or does it do updates in a more controlled fashion that makes it avoid these issues? Thanks, Dmitry On Thu, Sep 26, 2013 at 5:24 PM, Shawn Heisey <s...@elyograg.org> wrote: > On 9/26/2013 6:43 AM, Dmitry Kan wrote: > > Can someone please help me understand the comment in solr 4.3.1's > > solrconfig.xml: > > > > <!-- Use Cold Searcher > > > > If a search request comes in and there is no current > > registered searcher, then immediately register the still > > warming searcher and use it. If "false" then all requests > > will block until the first searcher is done warming. > > --> > > <useColdSearcher>false</useColdSearcher> > > As I understand it, this only applies to Solr startup or core reload, > because that's the only time you'd normally have no registered > searchers. The warming queries in that case are defined by > firstSearcher and newSearcher events, they aren't your cache > autowarming. For cache autowarming, you have a registered searcher > already. > > Now I will answer a question that you asked on IRC early this morning > (in my timezone): If you are seeing messages in your log about > exceeding maxWarmingSearchers, then it is likely that the amount of time > that it takes for warming is exceeding the amount of time before the > next commit comes in. > > Thanks, > Shawn > >
