[
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
Attaching the simplest possible test case i found that fails. these are the
two queries, as mentioned before executing "match_1" before "match_0" and they
both return the correct number of results, but if you executed "match_0" first
then "match_1" doesn't match any documents...
{code}
SolrParams match_0
= params("q", "{!frange v=val_i l=0 u=1}",
"fq", "{!frange v=val_i l=1 u=1}",
"fq", "{!frange v=val_i l=0 u=1}",
"fq", "-_query_:\"{!frange v=val_i l=1 u=1}\"",
"fq", "-_query_:\"{!frange v=val_i l=0 u=1}\"");
SolrParams match_1
= params("q", "{!frange v=val_i l=0 u=1}",
"fq", "{!frange v=val_i l=0 u=1}",
"fq", "{!frange v=val_i l=0 u=1}",
"fq", "-_query_:\"{!frange v=val_i l=1 u=1}\"",
"fq", "-_query_:\"{!frange v=val_i l=1 u=1}\"");
{code}
2 important things i noticed while testing:
* if i removed duplicate & redundent {{fq=\{!frange v=val_i l=0 u=1\}}}
(redundent because it's identical to the q param) then the test started to pass
* if i change the _order_ of the fq's, then the test started to pass
That reminded me of SOLR-5057 which was included in 4.5.0. I tried applying
this patch to trunk, 4x, 4.6.0, 4.5.0, and 4.4.0 -- all of them failed except
4.4, leading me to the working hypothesis that the changes in SOLR-5057 caused
this problem.
When i reverted [r1516299|https://svn.apache.org/r1516299] on my trunk
checkout, both my new test and the original failing test (with the above
mentioned reproduce line) started to pass.
----
So it seems pretty clear to me that something related to SOLR-5057 is causing
false cache hits -- what isn't entirely clear to me yet is if the functionality
added in [r1516299|https://svn.apache.org/r1516299] is fundamentally flawed
(and should be reverted), or if it's just exposing some less obvious problem
with the hashCode/equals methods of these specific query types.
I'll keep digging - but if anyone can lend a pair of eyes to the logic in
[r1516299|https://svn.apache.org/r1516299] and chime in if you spot any
fallacies it would be appreciated.
> 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, SOLR-5618.patch, 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]
