lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jihwan Kim <jihwa...@gmail.com>
Subject Re: firstSearcher per SolrCore or JVM?
Date Tue, 04 Oct 2016 03:20:39 GMT
Thanks Eric.
FirstSearcher and newSearcher events open with two separate searchers.  For
the external file field case at least, the cache created with the
firstSearcher is not being used after the newSearcher creates another cache
(with same values)

I believe the warming is also per searcher.  So, I am still wondering why
two searcher is running during the core reload. (since the cache with the
firstSearcher is not used much)

On V 4.10.4, it seems the main (current) searcher is closed after
newSearcher event.  So, all cache is generated with a new searcher before
accepting a query with the new searcher.

On V. 6.2.0, the main (current) searcher is closed first and then the
newSearcher event is triggered.  So, the first HTTP request with an
external file field needs to wait until the cache is created with the
newSearcher.  In fact, two threads are running and I am not yet sure how
they are synchronised (or not synchronized)

Now sure, if I can attache an image here, but this is response time on V.
6.2.10



On Mon, Oct 3, 2016 at 9:00 PM, Erick Erickson <erickerickson@gmail.com>
wrote:

> firstSearcher and newSeacher are definitely per core, they have to be
> since they
> are intended to warm searchers and searchers are per core.
>
> I don't particularly see the benefit of firing them both either. Not
> sure which one makes
> the most sense though.
>
> Best,
> Erick
>
> On Mon, Oct 3, 2016 at 7:10 PM, Jihwan Kim <jihwan11@gmail.com> wrote:
> > I am using external file fields with larger external files and I noticed
> > Solr Core Reload loads external files twice: firstSearcher and
> nextSearcher
> > event.
> >
> > Does it mean the Core Reload triggers both events? What is the
> > benefit/reason of triggering both events at the same time?   I see this
> on
> > V. 4.10.4 and V. 6.2.0 both.
> >
> > Thanks,
>

Mime
  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message