[
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: [email protected]
For additional commands, e-mail: [email protected]
