[ 
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

bq. Probably most efficient for small lists would be to make a copy of one list 
and then remove equivalent elements as they are found.

Attached patch fixes the bug and adds some randomized testng on the 
QueryResultKey equality comparisons ensuring that both the positive and 
negative situations are covered.

(I'm still running full tests, but unless there are any objections i'll 
probably commit & backport to 4.6.1 ASAP)


> false query result cache hits possible when duplicate filter queries exist in 
> one query -- discovered via: Reproducible failure from 
> TestFiltering.testRandomFiltering
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: SOLR-5618
>                 URL: https://issues.apache.org/jira/browse/SOLR-5618
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.5, 4.5.1, 4.6
>            Reporter: Hoss Man
>            Assignee: Hoss Man
>             Fix For: 4.6.1
>
>         Attachments: SOLR-5618.patch, SOLR-5618.patch, SOLR-5618.patch, 
> SOLR-5618.patch, SOLR-5618.patch
>
>
> SOLR-5057 introduced a bug in queryResultCaching such that the following 
> circumstances can result in a false cache hit...
> * identical main query in both requests
> * identical number of filter queries in both requests
> * filter query from one request exists multiple times in other request
> * sum of hashCodes for all filter queries is equal in both request
> Details of how this problem was initially uncovered listed below...
> ----
> 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to