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

Hoss Man commented on SOLR-5122:
--------------------------------

Reviewing the comments in SOLR-3240 i think i just figured out hte "remove dead 
code" comment...

bq. I'm also thinking I can safely get rid of the "forceInorderCollection" flag 
because requesting docs sorted by doc-id would enforce the same thing, right?

...i don't think this assumption is valid.  I don't think using the {{_docid_}} 
sort option affects the order that collectors recieve docs, it's just used to 
register a {{SortField}} using {{SortField.Type.DOC}}, which isn't used until 
*after* the collector collects "all" of the docs.

So i think we need to add back in the FORCE_INORDER_COLLECTION
                
> "ArithmeticException: / by zero" using spellcheck.collateMaxCollectDocs
> -----------------------------------------------------------------------
>
>                 Key: SOLR-5122
>                 URL: https://issues.apache.org/jira/browse/SOLR-5122
>             Project: Solr
>          Issue Type: Bug
>    Affects Versions: 4.4
>            Reporter: Hoss Man
>         Attachments: SOLR-5122.patch
>
>
> As part of SOLR-4952 SpellCheckCollatorTest started using RandomMergePolicy, 
> and this (aparently) led to a failure in testEstimatedHitCounts.
> As far as i can tell: the test assumes that specific values would be returned 
> as the _estimated_ "hits" for a colleation, and it appears that the change in 
> MergePolicy however resulted in different segments with different term stats, 
> causing the estimation code to produce different values then what is expected.
> I made a quick attempt to improve the test to:
>  * expect explicit exact values only when spellcheck.collateMaxCollectDocs is 
> set such that the "estimate' should actually be exact (ie: 
> collateMaxCollectDocs  == 0 or collateMaxCollectDocs greater then the num 
> docs in the index
>  * randomize the values used for collateMaxCollectDocs and confirm that the 
> estimates are never more then the num docs in the index
> This lead to an odd "ArithmeticException: / by zero" error in the test, which 
> seems to suggest that there is a genuine bug in the code that only gets 
> tickled in certain mergepolicy/segment/collateMaxCollectDocs combinations.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to