[
https://issues.apache.org/jira/browse/SOLR-6160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034556#comment-14034556
]
ASF subversion and git services commented on SOLR-6160:
-------------------------------------------------------
Commit 1603310 from [~dsmiley] in branch 'dev/trunk'
[ https://svn.apache.org/r1603310 ]
SOLR-6160: bugfix when facet query or range with group facets and distributed
> 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
