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

Michael Gibney commented on SOLR-14520:
---------------------------------------

{quote}one concern i have that's still nagging me is how to reproduce the 2nd 
type of failure i mentioned above
{quote}
Yes, I'm not exactly sure. Looking just now, we only reach the problematic part 
of the code if {{facetInfo!=null}} _and_ {{skipFacet==false}}, which only 
happens for "partial" refinement buckets, which I don't understand well at the 
moment. Perhaps the key to reproducing might be to figure out how/when 
{{partialBuckets}} for subs are initially populated ({{"_p"}}), which it looks 
like happens in {{FacetRequestSortedMerger.getRefinement(...)}}? Although I 
don't understand it at the moment, it does look like it's indirectly determined 
by a bunch of conditional logic ... i.e., conditions that have to be satisfied 
in order for that part of the code to be exercised ... which at least could 
explain why it's hard to reproduce the problem? 

> json.facets: allBucket:true can cause server errors when combined with 
> refine:true
> ----------------------------------------------------------------------------------
>
>                 Key: SOLR-14520
>                 URL: https://issues.apache.org/jira/browse/SOLR-14520
>             Project: Solr
>          Issue Type: Bug
>          Components: Facet Module
>            Reporter: Chris M. Hostetter
>            Priority: Major
>         Attachments: SOLR-14520.patch, SOLR-14520.patch
>
>
> Another bug that was discovered while testing SOLR-14467...
> In some situations, using {{allBuckets:true}} in conjunction with 
> {{refine:true}} can cause server errors during the "refinement" requests to 
> the individual shards -- either NullPointerExceptions from some (nested) 
> SlotAccs when SpecialSlotAcc tries to collect them, or 
> ArrayIndexOutOfBoundsException from CountSlotArrAcc.incrementCount because 
> it's asked to collect to "large" slot# values even though it's been 
> initialized with a size of '1'
> NOTE: these problems may be specific to FacetFieldProcessorByArrayDV - i have 
> not yet seen similar failures from FacetFieldProcessorByArrayUIF (those are 
> the only 2 used when doing refinement) but that may just be a fluke of 
> testing.



--
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

Reply via email to