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