Solr
  1. Solr
  2. SOLR-5618

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

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.5, 4.5.1, 4.6
    • Fix Version/s: 4.6.1, 4.7, 6.0
    • Component/s: None
    • Labels:
      None

      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.

      1. SOLR-5618.patch
        14 kB
        Hoss Man
      2. SOLR-5618.patch
        5 kB
        Hoss Man
      3. SOLR-5618.patch
        3 kB
        Hoss Man
      4. SOLR-5618.patch
        3 kB
        Hoss Man
      5. SOLR-5618.patch
        1 kB
        Hoss Man

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          Relevant log snipper from jenkins...

             [junit4]   2> 558586 T3202 C2360 oasc.SolrCore.execute [collection1] webapp=null path=null params={q={!frange+v%3Dval_i+l%3D0+u%3D1+cost%3D139+tag%3Dt}&fq={!frange+v%3Dval_i+l%3D0+u%3D1}&fq={!+cost%3D92}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"&fq={!frange+v%3Dval_i+l%3D0+u%3D1+cache%3Dtrue+tag%3Dt}&fq={!+cache%3Dtrue+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"} hits=0 status=0 QTime=1 
             [junit4]   2> 558586 T3202 oas.SolrTestCaseJ4.assertJQ ERROR query failed JSON validation. error=mismatch: '1'!='0' @ response/numFound
             [junit4]   2> 	 expected =/response/numFound==1
             [junit4]   2> 	 response = {
             [junit4]   2> 	  "responseHeader":{
             [junit4]   2> 	    "status":0,
             [junit4]   2> 	    "QTime":1},
             [junit4]   2> 	  "response":{"numFound":0,"start":0,"docs":[]
             [junit4]   2> 	  }}
             [junit4]   2> 	
             [junit4]   2> 	 request = q={!frange+v%3Dval_i+l%3D0+u%3D1+cost%3D139+tag%3Dt}&fq={!frange+v%3Dval_i+l%3D0+u%3D1}&fq={!+cost%3D92}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"&fq={!frange+v%3Dval_i+l%3D0+u%3D1+cache%3Dtrue+tag%3Dt}&fq={!+cache%3Dtrue+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"
             [junit4]   2> 558587 T3202 oasc.SolrException.log ERROR java.lang.RuntimeException: mismatch: '1'!='0' @ response/numFound
             [junit4]   2> 		at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:732)
             [junit4]   2> 		at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:679)
             [junit4]   2> 		at org.apache.solr.search.TestFiltering.testRandomFiltering(TestFiltering.java:316)
          ...
             [junit4]   2> 558588 T3202 oass.TestFiltering.testRandomFiltering ERROR 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]   2> 558588 T3202 oas.SolrTestCaseJ4.tearDown ###Ending testRandomFiltering
             [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)
             [junit4]    > 	at java.lang.Thread.run(Thread.java:744)
          
          
          
          Show
          Hoss Man added a comment - Relevant log snipper from jenkins... [junit4] 2> 558586 T3202 C2360 oasc.SolrCore.execute [collection1] webapp=null path=null params={q={!frange+v%3Dval_i+l%3D0+u%3D1+cost%3D139+tag%3Dt}&fq={!frange+v%3Dval_i+l%3D0+u%3D1}&fq={!+cost%3D92}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"&fq={!frange+v%3Dval_i+l%3D0+u%3D1+cache%3Dtrue+tag%3Dt}&fq={!+cache%3Dtrue+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"} hits=0 status=0 QTime=1 [junit4] 2> 558586 T3202 oas.SolrTestCaseJ4.assertJQ ERROR query failed JSON validation. error=mismatch: '1'!='0' @ response/numFound [junit4] 2> expected =/response/numFound==1 [junit4] 2> response = { [junit4] 2> "responseHeader":{ [junit4] 2> "status":0, [junit4] 2> "QTime":1}, [junit4] 2> "response":{"numFound":0,"start":0,"docs":[] [junit4] 2> }} [junit4] 2> [junit4] 2> request = q={!frange+v%3Dval_i+l%3D0+u%3D1+cost%3D139+tag%3Dt}&fq={!frange+v%3Dval_i+l%3D0+u%3D1}&fq={!+cost%3D92}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}"&fq={!frange+v%3Dval_i+l%3D0+u%3D1+cache%3Dtrue+tag%3Dt}&fq={!+cache%3Dtrue+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D1+u%3D1}" [junit4] 2> 558587 T3202 oasc.SolrException.log ERROR java.lang.RuntimeException: mismatch: '1'!='0' @ response/numFound [junit4] 2> at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:732) [junit4] 2> at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:679) [junit4] 2> at org.apache.solr.search.TestFiltering.testRandomFiltering(TestFiltering.java:316) ... [junit4] 2> 558588 T3202 oass.TestFiltering.testRandomFiltering ERROR 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] 2> 558588 T3202 oas.SolrTestCaseJ4.tearDown ###Ending testRandomFiltering [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) [junit4] > at java.lang.Thread.run(Thread.java:744)
          Hide
          Hoss Man added a comment -

          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...

          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}"
          

          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?

          Show
          Hoss Man added a comment - 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... 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}" 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?
          Hide
          Hoss Man added a comment -

          I've recreated the failure conditions in a non-randomized test.

          See "testHossssSanity" in the updated patch for the details, but the bottom line is after building up two sets of SolrParams (match_1 and match_0), we have a situation where the following test code fails on the last line (match_1 gets a numFound==0)...

              // 1 then 0
              assertJQ(req(match_1), "/response/numFound==1");
              assertJQ(req(match_0), "/response/numFound==0");
          
              // clear caches
              assertU(commit());
          
              // 0 then 1
              assertJQ(req(match_0), "/response/numFound==0");
              assertJQ(req(match_1), "/response/numFound==1");
          

          ...which definitely smells like a caching bug.

          Perhaps this is a Query.equals() problem with one of the query classes used in the test? I'll investigate a bit more later today – starting with trying to simplify the params to the barest case that still fails.

          Show
          Hoss Man added a comment - I've recreated the failure conditions in a non-randomized test. See "testHossssSanity" in the updated patch for the details, but the bottom line is after building up two sets of SolrParams (match_1 and match_0), we have a situation where the following test code fails on the last line (match_1 gets a numFound==0)... // 1 then 0 assertJQ(req(match_1), "/response/numFound==1" ); assertJQ(req(match_0), "/response/numFound==0" ); // clear caches assertU(commit()); // 0 then 1 assertJQ(req(match_0), "/response/numFound==0" ); assertJQ(req(match_1), "/response/numFound==1" ); ...which definitely smells like a caching bug. Perhaps this is a Query.equals() problem with one of the query classes used in the test? I'll investigate a bit more later today – starting with trying to simplify the params to the barest case that still fails.
          Hide
          Hoss Man added a comment -

          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...

              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}\"");
          

          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 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 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 and chime in if you spot any fallacies it would be appreciated.

          Show
          Hoss Man added a comment - 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... 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}\""); 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 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 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 and chime in if you spot any fallacies it would be appreciated.
          Hide
          Hoss Man added a comment -

          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 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.

          Bug is definitely in the QueryResultKey.isEqual & QueryResultKey.unorderedCompare method – they ensure that fqList1 and fqList2 are the same size, and that every item from fqList1 exists in fqList2, but they don't ensure that there is a 1-to-1 set equivalence between the lists – So in cases where fqList1 contains some query X duplicated N times, it only ensures that X is in fqList2, but not that it's duplicated N times, so having some other clauses which are not in fqList1 to keep the sizes the same causes false positives.

          Targeted test case attached ... i'll work on a more robust randomized test tomorrow and see if i can figure out an efficinet fix, or if we should just revert r1516299 completely.

          Show
          Hoss Man added a comment - 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 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. Bug is definitely in the QueryResultKey.isEqual & QueryResultKey.unorderedCompare method – they ensure that fqList1 and fqList2 are the same size, and that every item from fqList1 exists in fqList2, but they don't ensure that there is a 1-to-1 set equivalence between the lists – So in cases where fqList1 contains some query X duplicated N times, it only ensures that X is in fqList2, but not that it's duplicated N times, so having some other clauses which are not in fqList1 to keep the sizes the same causes false positives. Targeted test case attached ... i'll work on a more robust randomized test tomorrow and see if i can figure out an efficinet fix, or if we should just revert r1516299 completely.
          Hide
          Hoss Man added a comment -

          Root cause of problem introduced in SOLR-5057

          Show
          Hoss Man added a comment - Root cause of problem introduced in SOLR-5057
          Hide
          Yonik Seeley added a comment -

          Ah, tricky.
          One could do for every X in fqList1, find an equiv in fqList2 and then
          for every X in fqList2, find an equiv in fqList1, but it's not particularly efficient.
          Probably most efficient for small lists would be to make a copy of one list and then remove equivalent elements as they are found. Not sure if it's worth it though...

          Show
          Yonik Seeley added a comment - Ah, tricky. One could do for every X in fqList1, find an equiv in fqList2 and then for every X in fqList2, find an equiv in fqList1, but it's not particularly efficient. Probably most efficient for small lists would be to make a copy of one list and then remove equivalent elements as they are found. Not sure if it's worth it though...
          Hide
          Hoss Man added a comment -

          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)

          Show
          Hoss Man added a comment - 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)
          Hide
          ASF subversion and git services added a comment -

          Commit 1556988 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1556988 ]

          SOLR-5618: Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests

          Show
          ASF subversion and git services added a comment - Commit 1556988 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1556988 ] SOLR-5618 : Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests
          Hide
          ASF subversion and git services added a comment -

          Commit 1556996 from hossman@apache.org in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1556996 ]

          SOLR-5618: Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests (merge r1556988)

          Show
          ASF subversion and git services added a comment - Commit 1556996 from hossman@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1556996 ] SOLR-5618 : Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests (merge r1556988)
          Hide
          ASF subversion and git services added a comment -

          Commit 1557008 from hossman@apache.org in branch 'dev/branches/lucene_solr_4_6'
          [ https://svn.apache.org/r1557008 ]

          SOLR-5618: Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests (merge r1556988)

          Show
          ASF subversion and git services added a comment - Commit 1557008 from hossman@apache.org in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1557008 ] SOLR-5618 : Fix false cache hits in queryResultCache when hashCodes are equal and duplicate filter queries exist in one of the requests (merge r1556988)
          Hide
          ASF subversion and git services added a comment -

          Commit 1557031 from hossman@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1557031 ]

          SOLR-5618: fix stupid test mistake

          Show
          ASF subversion and git services added a comment - Commit 1557031 from hossman@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1557031 ] SOLR-5618 : fix stupid test mistake
          Hide
          ASF subversion and git services added a comment -

          Commit 1557033 from hossman@apache.org in branch 'dev/branches/branch_4x'
          [ https://svn.apache.org/r1557033 ]

          SOLR-5618: fix stupid test mistake (merge r1557031)

          Show
          ASF subversion and git services added a comment - Commit 1557033 from hossman@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1557033 ] SOLR-5618 : fix stupid test mistake (merge r1557031)
          Hide
          ASF subversion and git services added a comment -

          Commit 1557034 from hossman@apache.org in branch 'dev/branches/lucene_solr_4_6'
          [ https://svn.apache.org/r1557034 ]

          SOLR-5618: fix stupid test mistake (merge r1557031)

          Show
          ASF subversion and git services added a comment - Commit 1557034 from hossman@apache.org in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1557034 ] SOLR-5618 : fix stupid test mistake (merge r1557031)

            People

            • Assignee:
              Hoss Man
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development