Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-user@lucene.apache.org
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: text/plain; CHARSET=US-ASCII
Subject: Re: QueryParser changes query by itself
To: solr-user@lucene.apache.org
References: <73193f1c-cbef-378e-152d-dff70461a6d9@uni-bielefeld.de>
 <910_1502817132_v7FHCAeg003228_1723543610.2179703.1502816843977@mail.yahoo.com>
From: Bernd Fehling <bernd.fehling@uni-bielefeld.de>
Message-id: <73bde89f-d0b4-e72a-e8c9-df6754c29bd7@uni-bielefeld.de>
Date: Wed, 16 Aug 2017 09:06:28 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101
 Thunderbird/52.2.1
In-reply-to: 
 <910_1502817132_v7FHCAeg003228_1723543610.2179703.1502816843977@mail.yahoo.com>
Content-language: de-DE
archived-at: Wed, 16 Aug 2017 07:06:40 -0000

Hi Ahmet,

thank you for your reply. I was also targeting towards QueryCache but
with your hint about LUCENE-3758 I have a better point to start with.

If the system is under high load and the the QueryCache is filled I have
a higher rate of changed queries.
In debug mode the "timing-->process-->query" of changed queries is always "0" zero.

The query parser "SynonymQParser" is self developed which uses QParserPlugin.
There is no caching inside and works for years.
Only compiled against recent Lucene/Solr and some modifications like
using Builder with newer Lucene versions.

I will test without query cache.
Wich one should be disabled, Query Result Cache?

Regards
Bernd


Am 15.08.2017 um 19:07 schrieb Ahmet Arslan:
> 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.fehling@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
>