lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-10834) test configs should be changed to stop using numeric based uniqueKey field
Date Wed, 14 Jun 2017 02:04:00 GMT


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...

$ 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(
   [junit4]    > 	at org.apache.solr.SolrTestCaseJ4.assertQ(
   [junit4]    > 	at org.apache.solr.spelling.suggest.SuggesterTest.testSuggestions(
   [junit4]    > 	at
   [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

Try the repro line...

ant test  -Dtestcase=SuggesterTest -Dtests.method=testSuggestions -Dtests.seed=A25FEA75E3598F8C
-Dtests.slow=true -Dtests.locale=he-IL -Dtests.timezone=Pacific/Gambier -Dtests.asserts=true



Try seed with whole test class...

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

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:
>             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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message