David Smiley created SOLR-6160:
----------------------------------
Summary: 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
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: [email protected]
For additional commands, e-mail: [email protected]
