Solr
  1. Solr
  2. SOLR-805

DisMax queries are not being cached in QueryResultCache

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.3
    • Fix Version/s: 1.4
    • Component/s: search
    • Labels:
      None
    • Environment:

      Using Sun JDK 1.5 and Solr 1.3.0 release on Windows XP

      Description

      I have a DisMax Search Handler set up in my solrconfig.xml to weight results based on which field a hit was found in. Results seem to be coming back fine, but the exact same query issued twice will not result in a cache hit.

      I have run far enough in the debugger to determine that the hashCode for the BooleanQuery object is returning a different value each time for the same query. This leads me to believe there is some random factor involved in it's calculation, such as a default Object hashCode() implementation somewhere in the chain. Non DisMax queries seem to be caching just fine.

      Where I see this behavior exhibited is on line 47 of the QueryResultKey constructor. I have not dug in far enough to determine exactly where the hashCode is being incorrectly calculated. I will try and dig in further tomorrow, but wanted to get some attention on the bug.

        Issue Links

          Activity

          Hide
          Todd Feak added a comment -

          The fix for this has been commited to Lucene under the linked issue. Should be resolved when the referenced Lucene library is upgraded.

          Show
          Todd Feak added a comment - The fix for this has been commited to Lucene under the linked issue. Should be resolved when the referenced Lucene library is upgraded.
          Hide
          Koji Sekiguchi added a comment -

          I'll commit today if there is no objections.

          $ svn status
          A      lib/lucene-queries-2.9-dev.jar
          D      lib/lucene-spellchecker-2.4.0.jar
          A      lib/lucene-snowball-2.9-dev.jar
          D      lib/lucene-analyzers-2.4.0.jar
          A      lib/lucene-spellchecker-2.9-dev.jar
          D      lib/lucene-core-2.4.0.jar
          A      lib/lucene-analyzers-2.9-dev.jar
          D      lib/lucene-highlighter-2.4.0.jar
          D      lib/lucene-memory-2.4.0.jar
          A      lib/lucene-core-2.9-dev.jar
          D      lib/lucene-queries-2.4.0.jar
          D      lib/lucene-snowball-2.4.0.jar
          A      lib/lucene-highlighter-2.9-dev.jar
          A      lib/lucene-memory-2.9-dev.jar
          
          Show
          Koji Sekiguchi added a comment - I'll commit today if there is no objections. $ svn status A lib/lucene-queries-2.9-dev.jar D lib/lucene-spellchecker-2.4.0.jar A lib/lucene-snowball-2.9-dev.jar D lib/lucene-analyzers-2.4.0.jar A lib/lucene-spellchecker-2.9-dev.jar D lib/lucene-core-2.4.0.jar A lib/lucene-analyzers-2.9-dev.jar D lib/lucene-highlighter-2.4.0.jar D lib/lucene-memory-2.4.0.jar A lib/lucene-core-2.9-dev.jar D lib/lucene-queries-2.4.0.jar D lib/lucene-snowball-2.4.0.jar A lib/lucene-highlighter-2.9-dev.jar A lib/lucene-memory-2.9-dev.jar
          Hide
          Koji Sekiguchi added a comment -

          Committed revision 707641. Thanks Todd!

          Show
          Koji Sekiguchi added a comment - Committed revision 707641. Thanks Todd!
          Hide
          Otis Gospodnetic added a comment -

          Does this call for 1.3.1 release in the very near future? Most Solr 1.3 DisMax users will probably not be able to figure this one out, yet it will hurt them.

          Show
          Otis Gospodnetic added a comment - Does this call for 1.3.1 release in the very near future? Most Solr 1.3 DisMax users will probably not be able to figure this one out, yet it will hurt them.
          Hide
          Todd Feak added a comment -

          I'm not sure if this will help with the decision or not, but I should clarify.

          This problem was not specifically with DisMax queries, though that's what I initially thought. It's with any query that would contain a MultiPhraseQuery within it. According to Yonik in the linked in bug, the SynonymFilter could inject this on a standard query. So, this problem isn't limited to DisMax, but it also may not encompass all DisMax queries.

          Show
          Todd Feak added a comment - I'm not sure if this will help with the decision or not, but I should clarify. This problem was not specifically with DisMax queries, though that's what I initially thought. It's with any query that would contain a MultiPhraseQuery within it. According to Yonik in the linked in bug, the SynonymFilter could inject this on a standard query. So, this problem isn't limited to DisMax, but it also may not encompass all DisMax queries.
          Hide
          Shalin Shekhar Mangar added a comment -

          Apart from this one, I don't think there are any major fixes for 1.3 branch. With Java based replication being in the trunk now, we can also plan for an early 1.4 release – replication alone is a huge user facing feature. Of course, we need some time for the new features to stabilize, therefore, 1.4 can't be done as quick as a 1.3.1 release can be.

          Show
          Shalin Shekhar Mangar added a comment - Apart from this one, I don't think there are any major fixes for 1.3 branch. With Java based replication being in the trunk now, we can also plan for an early 1.4 release – replication alone is a huge user facing feature. Of course, we need some time for the new features to stabilize, therefore, 1.4 can't be done as quick as a 1.3.1 release can be.
          Hide
          Chris Harris added a comment -

          I was trying to figure out exactly which revision of the Lucene trunk Koji's commit here was built against, since it doesn't seem to be stated here in JIRA or in the SVN log. If anyone else else is curious, the answer is Lucene r707499 – at least according to the MANIFEST.MF file in lib/lucene-core-2.9-dev.jar.

          Show
          Chris Harris added a comment - I was trying to figure out exactly which revision of the Lucene trunk Koji's commit here was built against, since it doesn't seem to be stated here in JIRA or in the SVN log. If anyone else else is curious, the answer is Lucene r707499 – at least according to the MANIFEST.MF file in lib/lucene-core-2.9-dev.jar.

            People

            • Assignee:
              Unassigned
              Reporter:
              Todd Feak
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development