[SOLR-5618] false query result cache hits possible when duplicate filter queries exist in one query -- discovered via: Reproducible failure from TestFiltering.testRandomFiltering

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 4.5, 4.5.1, 4.6
• Fix Version/s: 4.6.1, 4.7, 6.0
• Assignee: Chris M. Hostetter
• Reporter: Chris M. Hostetter
• Created: 08/Jan/14 00:25
• Updated: 09/May/16 18:52
• Resolved: 10/Jan/14 01:36

Description

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

   [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)

The seed fails consistently for me on trunk using java7, and on 4x using both java7 and java6 - details to follow in comment.

Issue Links

• is broken by: SOLR-5057 queryResultCache should not related with the order of fq's list