[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
