[
https://issues.apache.org/jira/browse/SOLR-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034369#comment-14034369
]
Peter Ciuffetti commented on SOLR-6160:
---------------------------------------
Confirming that this patch has resolved the issue in the SolrCloud environment
where it was initially discovered. Thanks! Let me know if you want me to
post any query logs or other data from the environment.
> Exception possible with group.facet, range faceting, with distributed search
> ----------------------------------------------------------------------------
>
> Key: SOLR-6160
> URL: https://issues.apache.org/jira/browse/SOLR-6160
> Project: Solr
> Issue Type: Bug
> Affects Versions: 4.7.1
> Reporter: David Smiley
> Attachments:
> SOLR-6160__bugfix_when_facet_query_or_range_with_group_facets_and_distributed.patch
>
>
> I'm seeing a hard to reproduce bug when the following conditions are true:
> * Distributed search
> * group=true with group.field=xxx and group.facet=true
> * facet=true with facet.field and facet.range
> On a sharded request (isShard=true, distrib=false) that has
> requestPurpose=GET_FIELDS, *sometimes* facet=true but sometimes it isn't.
> Apparently, sometimes the earlier GET_FACETS phase satisfies the faceting
> alone and sometimes more is done in GET_FIELDS. So *if* facet=true on such a
> request *and* facet.range is set (or perhaps facet.query), then the bug will
> hit. Specifically both the facet.range and facet.query logic will
> conditionally call SimpleFacets.getGroupedFacetQueryCount, and both will
> conditionally do so when they detect that "group.field" has been set. BUT,
> for a GET_FIELDS shard request, the "group" parameter flag is explicitly
> removed from the request by StoredFieldsShardRequestFactory, effectively
> disabling grouping. So SimpleFacets.getGroupedFacetQueryCount will throw an
> error. The error is that "group.field" hasn't been set which technically
> isn't true.
> It's 100% reproducible on my customer's system. Reproducing it is tricky
> because it's not going to happen if the faceting logic doesn't happen on
> GET_FIELDS, which doesn't seem to happen often. I found that for a test
> query if I changed the facet.limit to a sufficiently high number then it
> trips, but if it's low then it doesn't. I presume this has something to do
> with refining faceting counts such that a higher facet.limit increases the
> chance that the coordinating node (what do we call that?) will need to ask a
> shard for more counts beyond which was provided on the initial GET_FACETS
> phase.
> If anyone has pointers on how to reproduce this (such as in a test!), then
> that would help.
> Even though I don't have 100% understanding of the bug and have yet to
> reproduce it with test data, it seems to me the bug might be as simple as
> having SimpleFacets.getGroupedFacetQueryCount retrieve the group.field
> parameter directly from parameters instead of possibly failing to find it in
> rb.GetGroupingSpec() (because "group" wasn't set). After all, that is how
> the callers of this method determine wether or not they want to get a grouped
> query count.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
