lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF subversion and git services (JIRA)" <>
Subject [jira] [Commented] (SOLR-6160) Exception possible with group.facet, range faceting, with distributed search
Date Tue, 17 Jun 2014 23:03:06 GMT


ASF subversion and git services commented on SOLR-6160:

Commit 1603310 from [~dsmiley] in branch 'dev/trunk'
[ ]

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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message