lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Smith <>
Subject Identical query returning different aggregate results
Date Tue, 16 Dec 2014 17:17:05 GMT
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:,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"}}, 

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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message