Chris,
Yes, your suggestion worked. Changing the parameter in my query from
...f.eventDate.facet.mincount=1...
to
...f.eventDate.facet.mincount=0...
worked around the problem. And I agree that SOLR-6154 describes what I observed
almost exactly. Once 5.0 is available, I'll test this again with "mincount=1".
Thanks everyone for your help! It is very much appreciated.
Regards,
David
On Tuesday, December 16, 2014 4:38 PM, Chris Hostetter
<hossman_luc...@fucit.org> wrote:
sounds like this bug...
https://issues.apache.org/jira/browse/SOLR-6154
...in which case it has nothing to do with your use of multiple
collections, it's just dependent on wether or not the first node to
respond happens to have a doc in every "range bucket" .. any bucket
missing (because of your mincount=1) from the first core to
respond is then ignored in the response fro mthe subsequent cores.
workarround is to set mincount=0 for your facet ranges.
: Date: Tue, 16 Dec 2014 17:17:05 +0000 (UTC)
: From: David Smith <dsmiths...@yahoo.com.invalid>
: Reply-To: solr-user@lucene.apache.org, David Smith <dsmiths...@yahoo.com>
: To: Solr-user <solr-user@lucene.apache.org>
: Subject: Identical query returning different aggregate results
:
: I have a prototype SolrCloud 4.10.2 setup with 13 collections (of 1 replica,
1 shard each) and a separate 1-node Zookeeper 3.4.6.
: The very first app test case I wrote is failing intermittently in this
environment, when I only have 4 documents ingested into the cloud.
: I dug in and found when I query against multiple collections, using the
"collection=" parameter, the aggregates I request are correct about 50% of the
time. The other 50% of the time, the aggregate returned by Solr is not
correct. Note this is for the identical query. In other words, I can run the
same query multiple times in a row, and get different answers.
:
: The simplest version of the query that still exhibits the odd behavior is as
follows:
:
http://192.168.59.103:8985/solr/query_handler/query?facet.range=eventDate&f.eventDate.facet.range.end=2014-12-31T23:59:59.999Z&f.eventDate.facet.range.gap=%2B1DAY&fl=eventDate,id&start=0&collection=2014_04,2014_03&rows=10&f.eventDate.facet.range.start=2014-01-01T00:00:00.000Z&q=*:*&f.eventDate.facet.mincount=1&facet=true
:
: When it SUCCEEDS, the aggregate correctly appears like this:
:
: "facet_counts":{ "facet_queries":{}, "facet_fields":{},
"facet_dates":{}, "facet_ranges":{ "eventDate":{ "counts":[
"2014-04-01T00:00:00Z",3], "gap":"+1DAY",
"start":"2014-01-01T00:00:00Z", "end":"2015-01-01T00:00:00Z"}},
"facet_intervals":{}}}
:
: When it FAILS, note that the counts[] array is empty:
: "facet_counts":{ "facet_queries":{}, "facet_fields":{},
"facet_dates":{}, "facet_ranges":{ "eventDate":{ "counts":[],
"gap":"+1DAY", "start":"2014-01-01T00:00:00Z",
"end":"2015-01-01T00:00:00Z"}}, "facet_intervals":{}}}
:
: If I further simplify the query, by removing range options or reducing to one
(1) collection name, then the problem goes away.
:
: The solr logs are clean at INFO level, and there is no substantive difference
in log output when the query succeeds vs fails, leaving me stumped where to
look next. Suggestions welcome.
: Regards,
: David
:
:
:
:
:
-Hoss
http://www.lucidworks.com/
