You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "Chris M. Hostetter (Jira)" <ji...@apache.org> on 2020/01/16 03:59:00 UTC
[jira] [Reopened] (LUCENE-9068) Build FuzzyQuery automata up-front
[ https://issues.apache.org/jira/browse/LUCENE-9068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Chris M. Hostetter reopened LUCENE-9068:
----------------------------------------
this commit seems to correspond with a huge number of new failures in org.apache.solr.search.FuzzySearchTest.testTooComplex ...
* http://fucit.org/solr-jenkins-reports/failure-report.html
* http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.FuzzySearchTest.testTooComplex
seed that repro's for me...
{noformat}
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=FuzzySearchTest -Dtests.method=testTooComplex -Dtests.seed=A7DC68948F1B6569 -Dtests.nightly=true -Dtests.slow=true -Dtests.badapples=true -Dtests.locale=en-RW -Dtests.timezone=Egypt -Dtests.asserts=true -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 3.56s | FuzzySearchTest.testTooComplex <<<
[junit4] > Throwable #1: junit.framework.AssertionFailedError: Unexpected exception type, expected RemoteSolrException but got org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:46249/solr/c1]
[junit4] > at __randomizedtesting.SeedInfo.seed([A7DC68948F1B6569:717E22B090C85623]:0)
[junit4] > at org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2752)
[junit4] > at org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2740)
[junit4] > at org.apache.solr.search.FuzzySearchTest.testTooComplex(FuzzySearchTest.java:64)
[junit4] > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit4] > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[junit4] > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit4] > at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[junit4] > at java.base/java.lang.Thread.run(Thread.java:834)
[junit4] > Caused by: org.apache.solr.client.solrj.SolrServerException: No live SolrServers available to handle this request:[http://127.0.0.1:46249/solr/c1]
[junit4] > at org.apache.solr.client.solrj.impl.LBSolrClient.request(LBSolrClient.java:345)
[junit4] > at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.sendRequest(BaseCloudSolrClient.java:1143)
[junit4] > at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.requestWithRetryOnStaleState(BaseCloudSolrClient.java:906)
[junit4] > at org.apache.solr.client.solrj.impl.BaseCloudSolrClient.request(BaseCloudSolrClient.java:838)
[junit4] > at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
[junit4] > at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1003)
[junit4] > at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1018)
[junit4] > at org.apache.solr.search.FuzzySearchTest.lambda$testTooComplex$0(FuzzySearchTest.java:64)
[junit4] > at org.apache.lucene.util.LuceneTestCase._expectThrows(LuceneTestCase.java:2870)
[junit4] > at org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2745)
[junit4] > ... 41 more
{noformat}
If i had to guess based on the failure issue description and the test failure message: when/where FuzzyQuery throws an exception has changed, so we're probably getting an uncaught exception (or a new exception type?) in a place solr isn't expecting it, leading solr to treat it as a server error instead of a user error.
maybe?
> Build FuzzyQuery automata up-front
> ----------------------------------
>
> Key: LUCENE-9068
> URL: https://issues.apache.org/jira/browse/LUCENE-9068
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Priority: Major
> Fix For: 8.5
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> FuzzyQuery builds a set of levenshtein automata (one for each possible edit distance) at rewrite time, and passes them between different TermsEnum invocations using an attribute source. This seems a bit needlessly complicated, and also means that things like visiting a query end up building the automata again. We should instead build the automata at query construction time, which is how AutomatonQuery does it.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org