Hoss Man commented on SOLR-12343:

[~ysee...@gmail.com] - i've been testing this out with the SKG (relatedness()) 
function -- where i initially discovered bug -- and trying to remove the 
workarounds for this that are currently in TestCloudJSONFacetSKG (grep for 
SOLR-12343) but i'm seeing some failures that I think i've traced back to a 
mistake in isBucketComplete() that _only_ affects facets using 
{{processEmpty:true}} ...

in {{getRefinement()}} you've got {{returnedAllBuckets}} taking into 
consideration {{processEmpty:true}} -- so that even if a shardA doesn't say it 
has {{more:true}} we will still send it candidate bucketX for refinement if we 
didn't explicitly {{saw}} bucketX on shardA.  so far so good.

but then, once all the refinement is done, and we have a fully refined bucketX 
it might now sort "lower" then an incomplete bucketY ... and 
{{isBucketComplete}} doesn't pay any attention to {{processEmpty:true}} ... so 
it sees that shardA does *not* have {{more:true}} and thinks (the incomplete) 
bucketY is ok to return.

...I'll work up an isolated test case

> JSON Field Facet refinement can return incorrect counts/stats for sorted 
> buckets
> --------------------------------------------------------------------------------
>                 Key: SOLR-12343
>                 URL: https://issues.apache.org/jira/browse/SOLR-12343
>             Project: Solr
>          Issue Type: Bug
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Hoss Man
>            Assignee: Yonik Seeley
>            Priority: Major
>         Attachments: SOLR-12343.patch, SOLR-12343.patch, SOLR-12343.patch, 
> SOLR-12343.patch, SOLR-12343.patch, SOLR-12343.patch
> The way JSON Facet's simple refinement "re-sorts" buckets after refinement 
> can cause _refined_ buckets to be "bumped out" of the topN based on the 
> refined counts/stats depending on the sort - causing _unrefined_ buckets 
> originally discounted in phase#2 to bubble up into the topN and be returned 
> to clients *with inaccurate counts/stats*
> The simplest way to demonstrate this bug (in some data sets) is with a 
> {{sort: 'count asc'}} facet:
>  * assume shard1 returns termX & termY in phase#1 because they have very low 
> shard1 counts
>  ** but *not* returned at all by shard2, because these terms both have very 
> high shard2 counts.
>  * Assume termX has a slightly lower shard1 count then termY, such that:
>  ** termX "makes the cut" off for the limit=N topN buckets
>  ** termY does not make the cut, and is the "N+1" known bucket at the end of 
> phase#1
>  * termX then gets included in the phase#2 refinement request against shard2
>  ** termX now has a much higher _known_ total count then termY
>  ** the coordinator now sorts termX "worse" in the sorted list of buckets 
> then termY
>  ** which causes termY to bubble up into the topN
>  * termY is ultimately included in the final result _with incomplete 
> count/stat/sub-facet data_ instead of termX
>  ** this is all indepenent of the possibility that termY may actually have a 
> significantly higher total count then termX across the entire collection
>  ** the key problem is that all/most of the other terms returned to the 
> client have counts/stats that are the cumulation of all shards, but termY 
> only has the contributions from shard1
> Important Notes:
>  * This scenerio can happen regardless of the amount of overrequest used. 
> Additional overrequest just increases the number of "extra" terms needed in 
> the index with "better" sort values then termX & termY in shard2
>  * {{sort: 'count asc'}} is not just an exceptional/pathelogical case:
>  ** any function sort where additional data provided shards during refinement 
> can cause a bucket to "sort worse" can also cause this problem.
>  ** Examples: {{sum(price_i) asc}} , {{min(price_i) desc}} , {{avg(price_i) 
> asc|desc}} , etc...

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to