[
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
