Hi Bernd, In LUCENE-3758, a new member field added into ComplexPhraseQuery class. But we didn't change its hashCode method accordingly. This caused anomalies in Solr, and Yonik found the bug and fixed hashCode. Your e-mail somehow reminded me this. Could it be the QueryCache and hashCode method/implementation of Query subclasses. May be your good and bad example is producing same hashCode? And this is confusing query cache in solr? Can you disable the query cache, to test it? By the way, which query parser are you using? I believe SynonymQuery is produced by BM25 similarity, right?
Ahmet On Friday, August 11, 2017, 2:48:07 PM GMT+3, Bernd Fehling <bernd.fehl...@uni-bielefeld.de> wrote: We just noticed a very strange problem with Solr 6.4.2 QueryParser. The QueryParser changes the query by itself from time to time. This happens if doing a search request reload several times at higher rate. Good example: ... <str name="q">textth:waffenhandel</str> <result name="response" numFound="85" start="0"> ... <str name="rawquerystring">textth:waffenhandel</str> <str name="querystring">textth:waffenhandel</str> <str name="parsedquery">+SynonymQuery(Synonym(textth:"arms sales" textth:"arms trade"... <str name="parsedquery_toString">+Synonym(textth:"arms sales" textth:"arms trade"... Bad example: ... <str name="q">textth:waffenhandel</str> <result name="response" numFound="20459" start="0"> ... <str name="rawquerystring">textth:waffenhandel</str> <str name="querystring">textth:waffenhandel</str> <str name="parsedquery">+textth:rss</str> <str name="parsedquery_toString">+textth:rss</str> As you can see in the bad example after several reloads the parsedquery changed to term "rss". But the original querystring has no "rss" substring at all. That is really strange. Anyone seen this before? Single index, Solr 6.4.2. Regards Bernd