Re: Why do I get different results for the same query with two Solr versions?

[Tulsi Das]

Can you post the managed schema and solrconfig content here ?

Do try the solr admin analysis screen
once as well to see the behaviour for this field.

https://lucene.apache.org/solr/guide/7_6/index.html

On Sun, 27 Dec, 2020, 6:54 pm nettadalet,  wrote:

> Thank you, that was helpful!
>
> For Solr 4.6 I get
> "parsedquery": "PhraseQuery(TITLE_ItemCode_t:\"ki 7\")"
>
> For Solr 7.5 I get
> "parsedquery":"+(+(TITLE_ItemCode_t:ki7 (+TITLE_ItemCode_t:ki
> +TITLE_ItemCode_t:7)))"
>
> So this is the cause of the difference in the search result, but I still
> don't know why the parsedquery is different between the two versions.
> Any idea/guess?
> Is it some internal implementation that changed sometime between 4.6 and
> 7.5?
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Re: Re:Re: Why do I get different results for the same query with two Solr versions?

[Tulsi Das]

Hi ,
Yes this look like related to sow (split on whitespace) param default
behaviour change in solr 7.

The sow parameter (short for "Split on Whitespace") now defaults to
false, which allows support for multi-word synonyms out of the box.
This parameter is used with the eDismax and standard/"lucene" query
parsers. If this parameter is not explicitly specified as true, query
text will not be split on whitespace before analysis.

https://lucene.apache.org/solr/guide/7_0/major-changes-in-solr-7.html


On Sun, 27 Dec, 2020, 8:25 pm nettadalet,  wrote:

> I added "defType=lucene" to both searches to make sure I use the same query
> parser, but it didn't change the results.
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Re: Why do I get different results for the same query with two Solr versions?

[Tulsi Das]

Hi,
Try adding debug=true or debug=query in the url and see the formed query at
the end .
You will get to know why the results are different.


On Thu, 24 Dec, 2020, 8:05 pm nettadalet,  wrote:

> Hello,
>
> I have the the same field type defined in Solr 4.6 and Solr 7.5. When I
> search with both versions, I get different results, and I don't know why
>
> I have the following *field type definition in Solr 4.6*:
>  positionIncrementGap="1000">
> 
> 
> 
>  words="stopwords.txt" />
>  generateWordParts="1"
> generateNumberParts="1" catenateWords="1" catenateNumbers="1"
> catenateAll="0" splitOnCaseChange="0"/>
> 
> 
> 
> 
> 
>  synonyms="synonyms.txt"
> ignoreCase="true" expand="true"/>
>  ignoreCase="true"
> words="stopwords.txt"
> />
>  generateWordParts="1"
> generateNumberParts="1" catenateWords="0" catenateNumbers="0"
> catenateAll="0" splitOnCaseChange="0"/>
> 
> 
> 
>
>
> I have the following *field type definition in Solr 7.5*:
>  positionIncrementGap="1000">
> 
> 
> 
>  words="stopwords.txt" />
>  generateWordParts="1"
> generateNumberParts="1" catenateWords="1" catenateNumbers="1"
> catenateAll="0" splitOnCaseChange="0"/>
> 
> 
> 
> 
> 
> 
>  synonyms="synonyms.txt"
> ignoreCase="true" expand="true"/>
> ignoreCase="true"
>words="stopwords.txt"
>/>
>  generateWordParts="1"
> generateNumberParts="1" catenateWords="0" catenateNumbers="0"
> catenateAll="0" splitOnCaseChange="0"/>
> 
> 
> 
>
> * I tried to use solr.WordDelimiterFilterFactory with Solr 7.5 instead of
> solr.WordDelimiterGraphFilterFactory so the field types will be more alike,
> but the result was the same.
>
> I have the following *6 values set for field text1 of type text_type1 for 6
> different documents* (the type(s) from above):
> KI_d5e7b43a
> KI_b7c490bd
> KI_7df2f026
> KI_fa7d129d
> KI_5867aec7
> KI_7c3c0b93
>
>
> My query is *text1=KI_7*.
> Using Solr 4.6, I get 2 result - KI_7df2f026, KI_7c3c0b93
> Using Solr 7.5, I get all 6 results.
>
> Questions:
> 1. How come I get different results with the same data, when my fields
> definitions are the same (as far as I can tell)?
>
> 2. What are the expected results?
> I think that the results Solr 7.5 returns are the correct ones, since at
> the
> end of the of the analysis I get *KA* as a term and *7* as a term, both
> during the indexing analysis and the query analysis, so, to my
> understanding, all 6 results should be found.
> Is this correct? if not, what am I missing? what don't I understand
> correctly?
>
> I would very much appreciate a full/partial answer, but even a link that
> could explain at least the expected results part would be great.
>
> Thanks in advance, I know this might be a tough one to answer [Hope not
> :)]
>
>
>
> --
> Sent from: https://lucene.472066.n3.nabble.com/Solr-User-f472068.html
>

Re: Modify partial configsets using API

[Tulsi Das]

That's right Mike.

If same config set is used for multiple collection , changing any file in
this would apply to other collections as well.

On Wed, May 8, 2019 at 11:49 PM Mike Drob  wrote:

>
>
> On 2019/05/08 16:52:52, Shawn Heisey  wrote:
> > On 5/8/2019 10:50 AM, Mike Drob wrote:
> > > Solr Experts,
> > >
> > > Is there an existing API to modify just part of my configset, for
> example
> > > synonyms or stopwords? I see that there is the schema API, but that is
> > > pretty specific in scope.
> > >
> > > Not sure if I should be looking at configset API to upload a zip with a
> > > single file, or if there are more granular options available.
> >
> > Here's a documentation link for managed resources:
> >
> > https://lucene.apache.org/solr/guide/6_6/managed-resources.html
> >
> > That's the 6.6 version of the documentation.  If you're running
> > something newer, which seems likely since 6.6 is quite old now, you
> > might want to look into a later documentation version.
> >
> > Thanks,
> > Shawn
> >
>
> Thanks Shawn, this looks like it will fit the bill nicely!
>
> One more question that I don't see covered in the documentation - if I
> have multiple collections sharing the same config set, does updating the
> managed stop words for one collection apply the change to all? Is this
> change persisted in zookeeper?
>
> Mike
>

Re: Shard and replica went down in Solr 6.1.0

[Tulsi Das]

Hi Vishal,
autosoftcommit of 1 sec could be the reason for this issue.
Choose autosoftcommit value as long an interval as your application can
tolerate, often 15-60 seconds is reasonable, or even longer depending on
the requirements
Also consider disabling your caches (queryResultCache and filterCache
especially) unless its required.

On Thu, Apr 11, 2019 at 10:40 PM vishal patel 
wrote:

> Actually in our application , bulky documents are needed to index and on
> same time we want to see that documents. So in production we keep auto
> commit 10 minutes and auto soft commit 1 second.
> Is it ohk?
>
> Get Outlook for Android
>
>
>
> 
> From: Erick Erickson 
> Sent: Thursday, April 11, 2019 10:23:00 PM
> To: vishal patel
> Subject: Re: Shard and replica went down in Solr 6.1.0
>
> We’re not quite on the same page.
>
> These config options will _not_ open any new searchers. Period. They’re
> not the source of your max warming searchers error. Therefore _somebody_ is
> issuing commits. You need to find out who and stop them.
>
> Then change your settings in solrconfig to
> 1> remove maxDoc from autoCommit. It’s probably leading to useless work
> 2> I’d shorten my maxTime in autoCommit to, say, 1 minute. This isn’t very
> important, but 10 minutes is unnecessary
> 3> Change your autoSoftCommit to as long as your application can tolerate,
> say 10 minutes if possible.
> 4> Find out who is issuing commits and stop them.
>
> With these settings, unless you have outrageous “autowarmCount” settings
> in solrconfig.xml for the caches, you should not see any overlapping on
> deck searchers. I usually start with autowarmCount settings in the 10-16
> range.
>
> Best,
> Erick
>
> > On Apr 11, 2019, at 5:40 AM, vishal patel 
> wrote:
> >
> >
> > Thanks Erick,
> > I got your point. As per you, Solr will not go down due to “performance
> warning” and no need to change the maxdoc value. You talked about number of
> searchers but in solrconfig.xml there is only
> 2.[2]
> >
> > In production, we have 27 collection, 2 shards and 2 replicas and 3 zoo
> keepers and more than 3 documents indexed within a 10 minutes.
> > How can I know how many searchers are open at the specific time?
> > As per my understanding, solr searcher will open when soft or hard
> commit. Am I right? And my commit time below
> > 
> > 60
> > 2
> > false
> > 
> >
> > 
> > ${solr.autoSoftCommit.maxTime:-1}
> > 
> >
> > I do not write any code for opening the solr index searcher and can not
> find any error related that.
> >
> > My all collection has same configuration mean same hard and soft commit
> time for all 27 collection. is it any issue if on same time two or more
> collections will come for hard commit?
> >
> > Below, again send more and accurate log details.
> >
> > Shard-1 Log ::
> > --
> > 2019-04-08 12:54:01.395 INFO  (commitScheduler-102-thread-1)
> [c:collection1 s:shard1 r:core_node1 x:collection1]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2019-04-08 12:54:01.395 INFO  (commitScheduler-118-thread-1)
> [c:collection2 s:shard1 r:core_node1 x:collection2]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2019-04-08 12:54:01.395 INFO  (commitScheduler-110-thread-1)
> [c:collection3 s:shard1 r:core_node1 x:collection3]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2019-04-08 12:54:01.394 INFO  (commitScheduler-109-thread-1)
> [c:collection4 s:shard1 r:core_node1 x:collection4]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> > 2019-04-08 12:54:01.394 INFO  (commitScheduler-99-thread-1)
> [c:collection5 s:shard1 r:core_node1 x:collection5]
> o.a.s.u.DirectUpdateHandler2 start
> commit{,optimize=false,openSearcher=false,waitSearcher=true,expungeDeletes=false,softCommit=false,prepareCommit=false}
> >
> > 2019-04-08 12:54:01.405 ERROR
> (updateExecutor-2-thread-36358-processing-http:
> 10.101.111.80:8983//solr//product x:product r:core_node1
> n:10.102.119.85:8983_solr s:shard1 c:product) [c:product s:shard1
> r:core_node1 x:product] o.a.s.u.StreamingSolrClients error
> > org.apache.solr.common.SolrException: Service Unavailable
> >
> >
> >
> > request:
> http://10.101.111.80:8983/solr/product/update?update.distrib=FROMLEADER=http%3A%2F%2F10.102.119.85%3A8983%2Fsolr%2Fproduct%2F=javabin=2
> > at
> org.apache.solr.client.solrj.impl.ConcurrentUpdateSolrClient$Runner.sendUpdateStream(ConcurrentUpdateSolrClient.java:320)
> > at
>