[
https://issues.apache.org/jira/browse/SOLR-10834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16048603#comment-16048603
]
Hoss Man commented on SOLR-10834:
---------------------------------
The current state of the branch is that all tests failures realted to numeric
uniqueKeys seem to be fixed.
I am however still seeing some fairly consistent failure from SuggesterTest and
it's subclasses -- which is odd because:
* none of these test classes have been modified on this branch
* none of the config files used by the tests have been modified on this branch
* no non-test code has been modified on this branch.
* these same tests don't seem to fail on master.
When a seed fails for one of these classes, the reproduce lines (to run that
single method) never seem to relibly fail -- but running all tests in the class
does fail, suggestion that it's a method ordering / test cleanup problem ...
but if that's the case why don't see see any failures from these on master
(from the same seed or any others?)
Example failure...
{noformat}
$ ant test -Dtestcase=SuggesterTest -Dtests.slow=true -Dtests.asserts=true
...
[junit4] 2> NOTE: reproduce with: ant test -Dtestcase=SuggesterTest
-Dtests.method=testSuggestions -Dtests.seed=A25FEA75E3598F8C -Dtests.slow=true
-Dtests.locale=he-IL -Dtests.timezone=Pacific/Gambier -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
[junit4] ERROR 0.20s | SuggesterTest.testSuggestions <<<
[junit4] > Throwable #1: java.lang.RuntimeException: Exception during
query
[junit4] > at
__randomizedtesting.SeedInfo.seed([A25FEA75E3598F8C:483D3802D6DD872]:0)
[junit4] > at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:890)
[junit4] > at
org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:857)
[junit4] > at
org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions(SuggesterTest.java:70)
[junit4] > at java.lang.Thread.run(Thread.java:748)
[junit4] > Caused by: java.lang.RuntimeException: REQUEST FAILED:
xpath=//lst[@name='spellcheck']/lst[@name='suggestions']/lst[@name='ac']/int[@name='numFound'][.='2']
[junit4] > xml response was: <?xml version="1.0" encoding="UTF-8"?>
[junit4] > <response>
[junit4] > <lst name="responseHeader"><int name="status">0</int><int
name="QTime">0</int></lst><lst name="spellcheck"><lst name="suggestions"><lst
name="ac"><int name="numFound">1</int><int name="startOffset">0</int><int
name="endOffset">2</int><arr
name="suggestion"><str>actually</str></arr></lst></lst><lst
name="collations"><str name="collation">actually</str></lst></lst>
[junit4] > </response>
[junit4] > request
was:q=ac&qt=/suggest&spellcheck.onlyMorePopular=true&spellcheck.count=2&wt=xml
{noformat}
Try the repro line...
{noformat}
ant test -Dtestcase=SuggesterTest -Dtests.method=testSuggestions
-Dtests.seed=A25FEA75E3598F8C -Dtests.slow=true -Dtests.locale=he-IL
-Dtests.timezone=Pacific/Gambier -Dtests.asserts=true
-Dtests.file.encoding=UTF-8
...
BUILD SUCCESSFUL
{noformat}
Try seed with whole test class...
{noformat}
ant test -Dtestcase=SuggesterTest -Dtests.seed=A25FEA75E3598F8C
-Dtests.slow=true -Dtests.locale=he-IL -Dtests.timezone=Pacific/Gambier
-Dtests.asserts=true -Dtests.file.encoding=UTF-8
...
[junit4] Tests with failures [seed: A25FEA75E3598F8C]:
[junit4] - org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions
{noformat}
But if i hammer on that test on master (same seed, randomized seed, whatever) I
can get it to pass 30+ times w/o fail.
I'll try to bisect this (on the branch) in the AM.
> test configs should be changed to stop using numeric based uniqueKey field
> --------------------------------------------------------------------------
>
> Key: SOLR-10834
> URL: https://issues.apache.org/jira/browse/SOLR-10834
> Project: Solr
> Issue Type: Test
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Hoss Man
>
> Apparently, once upon a time, as a way to prove that it worked and there were
> no hard coded "String" assumptions, some the {{schema.xml}} used by tests was
> written such that the uniqueKey field was definied as an "int".
> This has now snowballed such that there are at least 40 test schema files
> (just in solr/core!) that define the uniqueKey field using a Trie field
> (mostly TrieInt, but at least 2 TrieFloats!) despite the fact that at no
> point have we ever recommended/encouraged people to use anything other then
> StrField for their uniqueKey.
> that's nearly 1/3 of all the test schemas that we have -- which IIRC (from
> some early experiments in SOLR-10807) are used in more then half the
> solr/core tests.
> If we want to be able to deprecate/remove Trie fields in favor of point
> fields, we're really going to update all of these test schemas to use a
> StrField (we can't use PointFields as the uniqueKey due to the issues noted
> in SOLR-10829) ... but AFAICT that's going to require a non trivial amount of
> work due to many of these tests making explicit/implicit assumptions about
> the datatype of the uniqueKey field (ex: sorting by id, range queries on ids,
> casting stored field values returned by solrj, xpath expressions, etc...)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
