lucene-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christine Poerschke (Jira)" <j...@apache.org>
Subject [jira] [Commented] (LUCENE-8996) maxScore is sometimes missing from distributed grouped responses
Date Fri, 01 Nov 2019 19:59:00 GMT

    [ https://issues.apache.org/jira/browse/LUCENE-8996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16965059#comment-16965059
] 

Christine Poerschke commented on LUCENE-8996:
---------------------------------------------

Thanks [~munendrasn] and [~diegoceccarelli] for your input and insights!

Let me try to sum up things so far and what could be next.
 * The main objective of this bug fix ticket is to correctly return {{maxScore}} for groups
that are _not_ represented on all shards.
 ** Currently {{maxScore}} is missing because {{TopGroups.merge}} does a {{maxScore = Math.max(maxScore,
shardGroupDocs.maxScore);}} computation with assumptions.
 ** The computation assumes that {{shardGroupDocs.maxScore}} is always a number when in fact
it can be {{NaN}} if that group is not represented on that shard.
 ** {{Math.max(a, b)}} returns {{NaN}} if either value is {{NaN}}
 ** code links:
 *** [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.3.0/lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java#L172]
 *** [https://docs.oracle.com/javase/8/docs/api/java/lang/Math.html#max-float-float-]

 * We now know that {{shardGroupDocs.maxScore}} could also be absent if the group was represented
on the shard but _scores were not requested_.
 ** In this scenario changing {{TopGroups.merge}} to ignore any {{NaN}} scores had a side
effect as illustrated by the {{TestDistributedGrouping}} test failure.
 ** If all shards return a {{maxScore}} of {{NaN}} then the {{TopGroups.merge}} computation
(with {{nonNANmax}} instead of {{Math.max}}) will return as the overall result whatever the
initial value of the local {{maxScore}} variable was.
 ** The local {{maxScore}} variable is currently initialised to {{Float.MIN_VALUE}}.
 ** If scores were not requested then they should not be returned in the response (but as
per SOLR-6612 they currently are returned in distributed mode but not in non-distributed mode).

 * The {{TestDistributedGrouping}} logic could be adjusted to skip the {{maxScore}} comparison
(until SOLR-6612 is fixed) or the {{GroupedEndResultTransformer}} response composition logic
could be adjusted to screen out {{Float.MIN_VALUE}} scores but irrespective of that {{TopGroups.merge}}
returning a {{MIN_VALUE}} score if given (say) three {{NaN}} scores seems surprising and the
{{NaN}} that is currently being returned seems more logical.

 * If we changed the initialisation of the local {{maxScore}} variable from {{MIN_VALUE}}
to {{NaN}} then groups without scores would merge into an overall {{NaN}} i.e. no overall
score.
 * Local initialisation changes pose a backwards compatibility question: are there cases where
previously {{MIN_VALUE}} was returned and where now {{NaN}} would be returned instead?
 ** Code inspection shows that {{MIN_VALUE}} would be returned if the groups and shards for-loops
do not run.
 *** [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.3.0/lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java#L138-L227]
 *** The shards for-loop will always run since the no-shards case already resulted in a {{return}}
at L105.
 *** In the Apache Lucene/Solr code base there is only one non-test caller of the {{TopGroups.merge}}
method: [https://github.com/apache/lucene-solr/blob/releases/lucene-solr/8.3.0/solr/core/src/java/org/apache/solr/search/grouping/distributed/responseprocessor/TopGroupsShardResponseProcessor.java#L153-L168]
 *** The groups for-loop will always run since no-groups results in a {{continue}} at L156.

 * Per the above the local initialisation changes would pose no backwards compatibility concerns
within the Apache Lucene/Solr code base.
 * Considering any {{TopGroups.merge}} callers outside the Lucene/Solr code base, some {{lucene/CHANGES.txt}}
wording like the following could be used to document the change in behaviour. _"TopGroups.merge
now returns Float.NaN instead of Float.MIN_VALUE if no groups are passed as input."_
 * However, I would suggest that such wording would be unnecessary since merging empty group
arrays seems unlikely and exotic?

> maxScore is sometimes missing from distributed grouped responses
> ----------------------------------------------------------------
>
>                 Key: LUCENE-8996
>                 URL: https://issues.apache.org/jira/browse/LUCENE-8996
>             Project: Lucene - Core
>          Issue Type: Bug
>    Affects Versions: 5.3
>            Reporter: Julien Massenet
>            Assignee: Christine Poerschke
>            Priority: Minor
>         Attachments: LUCENE-8996.02.patch, LUCENE-8996.03.patch, LUCENE-8996.patch, LUCENE-8996.patch,
lucene_6_5-GroupingMaxScore.patch, lucene_solr_5_3-GroupingMaxScore.patch, master-GroupingMaxScore.patch
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> This issue occurs when using the grouping feature in distributed mode and sorting by
score.
> Each group's {{docList}} in the response is supposed to contain a {{maxScore}} entry
that hold the maximum score for that group. Using the current releases, it sometimes happens
that this piece of information is not included:
> {code}
> {
>   "responseHeader": {
>     "status": 0,
>     "QTime": 42,
>     "params": {
>       "sort": "score desc",
>       "fl": "id,score",
>       "q": "_text_:\"72\"",
>       "group.limit": "2",
>       "group.field": "group2",
>       "group.sort": "score desc",
>       "group": "true",
>       "wt": "json",
>       "fq": "group2:72 OR group2:45"
>     }
>   },
>   "grouped": {
>     "group2": {
>       "matches": 567,
>       "groups": [
>         {
>           "groupValue": 72,
>           "doclist": {
>             "numFound": 562,
>             "start": 0,
>             "maxScore": 2.0378063,
>             "docs": [
>               {
>                 "id": "29!26551",
>                 "score": 2.0378063
>               },
>               {
>                 "id": "78!11462",
>                 "score": 2.0298104
>               }
>             ]
>           }
>         },
>         {
>           "groupValue": 45,
>           "doclist": {
>             "numFound": 5,
>             "start": 0,
>             "docs": [
>               {
>                 "id": "72!8569",
>                 "score": 1.8988966
>               },
>               {
>                 "id": "72!14075",
>                 "score": 1.5191172
>               }
>             ]
>           }
>         }
>       ]
>     }
>   }
> }
> {code}
> Looking into the issue, it comes from the fact that if a shard does not contain a document
from that group, trying to merge its {{maxScore}} with real {{maxScore}} entries from other
shards is invalid (it results in NaN).
> I'm attaching a patch containing a fix.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org


Mime
View raw message