Hi Shawn, Thanks very much for the feedback.
Have tested using the routing mechanism/composite-id on a larger scale. Unfortunately the same behaviour. Regards Ronald -----Original Message----- From: Shawn Heisey [mailto:s...@elyograg.org] Sent: 29 May 2014 20:16 To: solr-user@lucene.apache.org Subject: COMMERCIAL: Re: SolrCloud: facet range option f.<field>.facet.mincount=1 omits buckets on response On 5/29/2014 12:06 PM, Ronald Matamoros wrote: > Hi all, > > At the moment I am reviewing the code to determine if this is a legitimate > bug that needs to be set as a JIRA ticket. > Any insight or recommendation is appreciated. <snip> > Note: the value in <int name="between"> changes with every other > refresh of the query. Whenever distributed search results change from one query to the next, it's almost always caused by having documents with the same uniqueKey in more than one shard. Solr is able to remove these duplicates from the results, but there are other aspects of distributed searching that cannot be dealt with when there are duplicate documents. This leads to problems like numFound changing from one request to the next. To avoid these problems with SolrCloud, you'll likely want to create a new collection and set its router to compositeId. This ensures that indexed documents are distributed to shards according to the hash of their uniqueKey, not imported directly into the node where you made the update request. It's possible that my guess here is completely wrong, but this is usually the problem. Thanks, Shawn
