You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Hoss Man (JIRA)" <ji...@apache.org> on 2014/01/08 03:07:50 UTC
[jira] [Updated] (SOLR-5618) Reproducible failure from
TestFiltering.testRandomFiltering
[ https://issues.apache.org/jira/browse/SOLR-5618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Hoss Man updated SOLR-5618:
---------------------------
Attachment: SOLR-5618.patch
This smells like a caching related bug ... but i have no idea why/where.
The test does multiple iterations where in each iteration it builds an index of a random number of documents, each containing an incremented value for "id" and "val_i" -- the number of documents can range from 1 to 21, with the id and val_i fields starting at "0". Then it generates a bunch of random requests consisting of random q and fq params.
This is what the failing request looks like...
{noformat}
q = {!frange v=val_i l=0 u=1 cost=139 tag=t}
fq = {!frange v=val_i l=0 u=1}
fq = {! cost=92}-_query_:"{!frange v=val_i l=1 u=1}"
fq = {!frange v=val_i l=0 u=1 cache=true tag=t}
fq = {! cache=true tag=t}-_query_:"{!frange v=val_i l=1 u=1}"
{noformat}
So basically: it will only ever match docs which have val_i==0 -- which given how the index is built means it should always match exactly 1 document: the 0th doc -- but in the failure message we can see that it doens't match any docs.
(FWIW: adding some debugging indicates that in the iteration where this fails, the index only has 2 documents in it -- doc#0 and doc#1)
In this patch i'm attaching, I hacked the test to explicitly attempt the above query in every iteration, regardless of the num docs in the index, immediately after building the index -- and that new assertion never fails. but then after it passes, it continues on with the existing logic, to generating a bunch of random requests and executing them -- and when it randomly generates the same query as above (that already succeeded in matching 1 doc against the current index) that query then fails to match any docs.
which smells to me like some sort of filter caching glitch .. right?
> Reproducible failure from TestFiltering.testRandomFiltering
> -----------------------------------------------------------
>
> Key: SOLR-5618
> URL: https://issues.apache.org/jira/browse/SOLR-5618
> Project: Solr
> Issue Type: Bug
> Reporter: Hoss Man
> Attachments: SOLR-5618.patch
>
>
> uwe's jenkins found this in java8...
> http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9004/consoleText
> {noformat}
> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering -Dtests.seed=C22042E80957AE3E -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=ar_LY -Dtests.timezone=Asia/Katmandu -Dtests.file.encoding=UTF-8
> [junit4] FAILURE 16.9s J1 | TestFiltering.testRandomFiltering <<<
> [junit4] > Throwable #1: java.lang.AssertionError: FAILURE: iiter=11 qiter=336 request=[q, {!frange v=val_i l=0 u=1 cost=139 tag=t}, fq, {!frange v=val_i l=0 u=1}, fq, {! cost=92}-_query_:"{!frange v=val_i l=1 u=1}", fq, {!frange v=val_i l=0 u=1 cache=true tag=t}, fq, {! cache=true tag=t}-_query_:"{!frange v=val_i l=1 u=1}"]
> [junit4] > at __randomizedtesting.SeedInfo.seed([C22042E80957AE3E:DD43E12DEC70EE37]:0)
> [junit4] > at org.apache.solr.search.TestFiltering.testRandomFiltering(TestFiltering.java:327)
> {noformat}
> The seed fails consistently for me on trunk using java7, and on 4x using both java7 and java6 - details to follow in comment.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org