Wow, advancing senility... _I'm_ actually the person that committed that fix...
Siiigggghhh. On Tue, Dec 16, 2014 at 5:38 PM, David Smith <dsmiths...@yahoo.com.invalid> wrote: > 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/ > >
