Re: Force open a searcher in solr.
Please don’t mess with _version_, that’s used internally for optimistic locking. I don’t have a clue, really, whether changing the definition will be deleterious or not. OTOH, that field was presumably defined by people who put the use of _version_ in in the first place, so changing it is just asking for trouble. In general, any variable defined with before-and-after underscores should be left strictly alone. Otherwise you’re on the right track. Best, Erick > On Aug 13, 2020, at 8:46 AM, Akshay Murarka wrote: > > So to make things clear, belows what I am expecting > > I have a document with a unique id field lets say "uniqueID". > This document has both stored/indexed and not stored/ not indexed fields > Currently I have my pop values in external files but I will instead define > a new field in schema (popVal) which will not be stored or indexed and have > docValues=true. > I am also moving _version_ field to indexed=false and stored=false, since I > don't have any case where I retrieve it and use it for searching. Just > hoping doing this doesn't cause any issues with updates in general (I read > that keeping this as not stored and not indexed is recommended since solr 7) > > Regards, > Akshay > > On Thu, Aug 13, 2020 at 4:53 PM Erick Erickson > wrote: > >> Let us know how it works. I want to be sure I’m not confusing you >> though. There isn’t a “doc ID field”. The structure of an eff file is >> docid:value >> >> where docid is your . What updating numerics does is allow >> you to update a field in a doc that’s identified by . That >> field is any name you want as long as it’s defined respecting >> the limitations in that link. >> >> Best, >> Erick >> >>> On Aug 13, 2020, at 6:30 AM, Akshay Murarka wrote: >>> >>> Hey Erick, >>> >>> Thanks for the information about the doc ID field. >>> So our external file values are single float value fields and we do use >>> them in functional queries in boost parameter, so based on the definition >>> the above should work. >>> So currently we use solr 5.4.0 but are in the process of upgrading our >>> systems so will try out this change. >>> >>> Regards, >>> Akshay >>> >>> On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson >> >>> wrote: >>> Right, but you can use those with function queries. Assuming your eff entry is a doc ID plus single numeric, I was wondering if you can accomplish what you need to with function queries... > On Aug 10, 2020, at 11:30 AM, raj.yadav >> wrote: > > Erick Erickson wrote >> Ah, ok. That makes sense. I wonder if your use-case would be better >> served, though, by “in place updates”, see: >> >> https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html >> This has been around in since Solr 6.5… > > As per documentation `in place update` is only available for numeric > docValues (along with few more conditions). And here its external field > type. > > Regards, > Raj > > > > -- > Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html >> >>
Re: Force open a searcher in solr.
So to make things clear, belows what I am expecting I have a document with a unique id field lets say "uniqueID". This document has both stored/indexed and not stored/ not indexed fields Currently I have my pop values in external files but I will instead define a new field in schema (popVal) which will not be stored or indexed and have docValues=true. I am also moving _version_ field to indexed=false and stored=false, since I don't have any case where I retrieve it and use it for searching. Just hoping doing this doesn't cause any issues with updates in general (I read that keeping this as not stored and not indexed is recommended since solr 7) Regards, Akshay On Thu, Aug 13, 2020 at 4:53 PM Erick Erickson wrote: > Let us know how it works. I want to be sure I’m not confusing you > though. There isn’t a “doc ID field”. The structure of an eff file is > docid:value > > where docid is your . What updating numerics does is allow > you to update a field in a doc that’s identified by . That > field is any name you want as long as it’s defined respecting > the limitations in that link. > > Best, > Erick > > > On Aug 13, 2020, at 6:30 AM, Akshay Murarka wrote: > > > > Hey Erick, > > > > Thanks for the information about the doc ID field. > > So our external file values are single float value fields and we do use > > them in functional queries in boost parameter, so based on the definition > > the above should work. > > So currently we use solr 5.4.0 but are in the process of upgrading our > > systems so will try out this change. > > > > Regards, > > Akshay > > > > On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson > > > wrote: > > > >> Right, but you can use those with function queries. Assuming your eff > >> entry is a doc ID plus single numeric, I was wondering if you can > >> accomplish what you need to with function queries... > >> > >>> On Aug 10, 2020, at 11:30 AM, raj.yadav > wrote: > >>> > >>> Erick Erickson wrote > Ah, ok. That makes sense. I wonder if your use-case would be better > served, though, by “in place updates”, see: > > >> > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > This has been around in since Solr 6.5… > >>> > >>> As per documentation `in place update` is only available for numeric > >>> docValues (along with few more conditions). And here its external field > >>> type. > >>> > >>> Regards, > >>> Raj > >>> > >>> > >>> > >>> -- > >>> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html > >> > >> > >
Re: Force open a searcher in solr.
Let us know how it works. I want to be sure I’m not confusing you though. There isn’t a “doc ID field”. The structure of an eff file is docid:value where docid is your . What updating numerics does is allow you to update a field in a doc that’s identified by . That field is any name you want as long as it’s defined respecting the limitations in that link. Best, Erick > On Aug 13, 2020, at 6:30 AM, Akshay Murarka wrote: > > Hey Erick, > > Thanks for the information about the doc ID field. > So our external file values are single float value fields and we do use > them in functional queries in boost parameter, so based on the definition > the above should work. > So currently we use solr 5.4.0 but are in the process of upgrading our > systems so will try out this change. > > Regards, > Akshay > > On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson > wrote: > >> Right, but you can use those with function queries. Assuming your eff >> entry is a doc ID plus single numeric, I was wondering if you can >> accomplish what you need to with function queries... >> >>> On Aug 10, 2020, at 11:30 AM, raj.yadav wrote: >>> >>> Erick Erickson wrote Ah, ok. That makes sense. I wonder if your use-case would be better served, though, by “in place updates”, see: >> https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html This has been around in since Solr 6.5… >>> >>> As per documentation `in place update` is only available for numeric >>> docValues (along with few more conditions). And here its external field >>> type. >>> >>> Regards, >>> Raj >>> >>> >>> >>> -- >>> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html >> >>
Re: Force open a searcher in solr.
Hey Erick, Thanks for the information about the doc ID field. So our external file values are single float value fields and we do use them in functional queries in boost parameter, so based on the definition the above should work. So currently we use solr 5.4.0 but are in the process of upgrading our systems so will try out this change. Regards, Akshay On Mon, Aug 10, 2020 at 10:19 PM Erick Erickson wrote: > Right, but you can use those with function queries. Assuming your eff > entry is a doc ID plus single numeric, I was wondering if you can > accomplish what you need to with function queries... > > > On Aug 10, 2020, at 11:30 AM, raj.yadav wrote: > > > > Erick Erickson wrote > >> Ah, ok. That makes sense. I wonder if your use-case would be better > >> served, though, by “in place updates”, see: > >> > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > >> This has been around in since Solr 6.5… > > > > As per documentation `in place update` is only available for numeric > > docValues (along with few more conditions). And here its external field > > type. > > > > Regards, > > Raj > > > > > > > > -- > > Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html > >
Re: Force open a searcher in solr.
Right, but you can use those with function queries. Assuming your eff entry is a doc ID plus single numeric, I was wondering if you can accomplish what you need to with function queries... > On Aug 10, 2020, at 11:30 AM, raj.yadav wrote: > > Erick Erickson wrote >> Ah, ok. That makes sense. I wonder if your use-case would be better >> served, though, by “in place updates”, see: >> https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html >> This has been around in since Solr 6.5… > > As per documentation `in place update` is only available for numeric > docValues (along with few more conditions). And here its external field > type. > > Regards, > Raj > > > > -- > Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Force open a searcher in solr.
Erick Erickson wrote > Ah, ok. That makes sense. I wonder if your use-case would be better > served, though, by “in place updates”, see: > https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html > This has been around in since Solr 6.5… As per documentation `in place update` is only available for numeric docValues (along with few more conditions). And here its external field type. Regards, Raj -- Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
Re: Force open a searcher in solr.
Ah, ok. That makes sense. I wonder if your use-case would be better served,
though, by “in place updates”, see:
https://lucene.apache.org/solr/guide/8_1/updating-parts-of-documents.html This
has been around in since Solr 6.5…
Best,
Erick
> On Aug 10, 2020, at 8:24 AM, Akshay Murarka wrote:
>
> Hey,
>
> So I have external file fields that have some data that get updated
> regularly. Whenever those get updated we need the open searcher operation
> to happen. The value in this external files are used in boosting and other
> function/range queries.
>
> On Mon, Aug 10, 2020 at 5:08 PM Erick Erickson
> wrote:
>
>> In a word, “no”. There is explicit code to _not_ open a new searcher if
>> the index hasn’t changed because it’s an expensive operation.
>>
>> Could you explain _why_ you want to open a new searcher even though the
>> index is unchanged? The reason for the check in the first place is that
>> nothing has changed about the index so the assumption is that there’s no
>> reason to open a new searcher.
>>
>> You could add at least one bogus doc on each shard, then delete them all
>> then issue a commit as a rather crude way to do this. Insuring that you
>> changed at least one doc on each shard is “an exercise for the reader”…
>>
>> Again, though, perhaps if you explained why you think this is necessary we
>> could suggest another approach. At first glance, this looks like an XY
>> problem though.
>>
>> Best,
>> Erick
>>
>>> On Aug 10, 2020, at 5:49 AM, Akshay Murarka wrote:
>>>
>>> Hey,
>>>
>>> I have a use case where none of the document in my solr index is
>> changing but I still want to open a new searcher through the curl api.
>>> On executing the below curl command
>>> curl
>> “XXX.XX.XX.XXX:9744/solr/mycollection/update?openSearcher=true=true”
>>> it doesn’t open a new searcher. Below is what I get in logs
>>>
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
>> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
>> o.a.s.u.DirectUpdateHandler2 start
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
>> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
>> o.a.s.u.DirectUpdateHandler2 start
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
>> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
>> o.a.s.u.DirectUpdateHandler2 start
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
>> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
>> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
>> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
>> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
>> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
>> o.a.s.u.DirectUpdateHandler2 start
>> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
>> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
>> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
>>> 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
>> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
>> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
>>> 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
>> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
>> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
>> org.apache.solr.search.SolrIndexSearcher
>>> 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
>> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
>> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
>> org.apache.solr.search.SolrIndexSearcher
>>> 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
>> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
>> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
>> org.apache.solr.search.SolrIndexSearcher
>>> 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
>> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
>> o.a.s.u.DirectUpdateHandler2 end_commit_flush
>>> 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
>> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
>> o.a.s.u.DirectUpdateHandler2
Re: Force open a searcher in solr.
Hey,
So I have external file fields that have some data that get updated
regularly. Whenever those get updated we need the open searcher operation
to happen. The value in this external files are used in boosting and other
function/range queries.
On Mon, Aug 10, 2020 at 5:08 PM Erick Erickson
wrote:
> In a word, “no”. There is explicit code to _not_ open a new searcher if
> the index hasn’t changed because it’s an expensive operation.
>
> Could you explain _why_ you want to open a new searcher even though the
> index is unchanged? The reason for the check in the first place is that
> nothing has changed about the index so the assumption is that there’s no
> reason to open a new searcher.
>
> You could add at least one bogus doc on each shard, then delete them all
> then issue a commit as a rather crude way to do this. Insuring that you
> changed at least one doc on each shard is “an exercise for the reader”…
>
> Again, though, perhaps if you explained why you think this is necessary we
> could suggest another approach. At first glance, this looks like an XY
> problem though.
>
> Best,
> Erick
>
> > On Aug 10, 2020, at 5:49 AM, Akshay Murarka wrote:
> >
> > Hey,
> >
> > I have a use case where none of the document in my solr index is
> changing but I still want to open a new searcher through the curl api.
> > On executing the below curl command
> > curl
> “XXX.XX.XX.XXX:9744/solr/mycollection/update?openSearcher=true=true”
> > it doesn’t open a new searcher. Below is what I get in logs
> >
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> > 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> >
> >
> > I don’t want to do a complete reload of my collection.
> > Is there any parameter that can be used to forcefully open a new
> searcher every time I do a commit with
Re: Force open a searcher in solr.
In a word, “no”. There is explicit code to _not_ open a new searcher if the
index hasn’t changed because it’s an expensive operation.
Could you explain _why_ you want to open a new searcher even though the index
is unchanged? The reason for the check in the first place is that nothing has
changed about the index so the assumption is that there’s no reason to open a
new searcher.
You could add at least one bogus doc on each shard, then delete them all then
issue a commit as a rather crude way to do this. Insuring that you changed at
least one doc on each shard is “an exercise for the reader”…
Again, though, perhaps if you explained why you think this is necessary we
could suggest another approach. At first glance, this looks like an XY problem
though.
Best,
Erick
> On Aug 10, 2020, at 5:49 AM, Akshay Murarka wrote:
>
> Hey,
>
> I have a use case where none of the document in my solr index is changing but
> I still want to open a new searcher through the curl api.
> On executing the below curl command
> curl
> “XXX.XX.XX.XXX:9744/solr/mycollection/update?openSearcher=true=true”
> it doesn’t open a new searcher. Below is what I get in logs
>
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=true,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> 2020-08-10 09:32:22.696 INFO (qtp297786644-6766) [c:mycollection
> s:shard1_1_1 r:core_node7 x:mycollection_shard1_1_1_replica1]
> o.a.s.u.DirectUpdateHandler2 No uncommitted changes. Skipping IW.commit.
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.c.SolrCore SolrIndexSearcher has not changed - not re-opening:
> org.apache.solr.search.SolrIndexSearcher
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6824) [c:mycollection
> s:shard1_1_0 r:core_node6 x:mycollection_shard1_1_0_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6819) [c:mycollection
> s:shard1_0_1 r:core_node5 x:mycollection_shard1_0_1_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
> 2020-08-10 09:32:22.697 INFO (qtp297786644-6829) [c:mycollection
> s:shard1_0_0 r:core_node4 x:mycollection_shard1_0_0_replica1]
> o.a.s.u.DirectUpdateHandler2 end_commit_flush
>
>
> I don’t want to do a complete reload of my collection.
> Is there any parameter that can be used to forcefully open a new searcher
> every time I do a commit with openSearcher=true
>
> Thanks in advance for the help
>
