Hi Bernd,
> On Aug 22, 2017, at 4:31 AM, Bernd Fehling
> wrote:
>
> But the QueryBuilder only calls "stream.reset()", it never calls
> "stream.end()" so that Filters
> in the Analyzer chain can't do any cleanup (like my Filter wanted to do).
> I moved my "cleanup" into reset() which feels like
Finally I solved the problem :-)
I don't know if it's a bug or a feature in org.apache.lucene.util.QueryBuilder
but I solved it in my Filter code which feels like a dirty hack.
The TokeStream API says in the docs:
https://lucene.apache.org/core/6_4_2/core/org/apache/lucene/analysis/TokenStream.ht
The queryCache shouldn't be involved, this is somehow an issue in
parsing (and Solr doesn't currently cache parsing).
Perhaps there is something shared in your SynonymQParser instances
that isn't quite thread safe?
It could also be something in the text analysis in lucene as well
(related to the ne
My class SynonymQParser which calls SolrQueryParserBase.parse :
class SynonymQParser extends QParser {
protected SolrQueryParser sqparser;
...
@Override
public Query parse() throws SyntaxError {
...
sqparser = new SolrQueryParser(this, defaultField);
sqparse
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-->qu
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
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:
...
textth:waffenhandel
...
textth:waffenhandel
textth:waffenhandel
+Syn
