Details
-
Bug
-
Status: Closed
-
Major
-
Resolution: Fixed
-
None
-
None
Description
Discovered this while working on SOLR-3218, but it's a general problem with how the code is designed (and the existing code even has a TODO in FacetRangeMerger refering to the problem) ... this is essentially the same bug FacetComponent's facet.range had that was fixed in SOLR-6154: When he coordinator "combines" the response from each shard, the buckets can get out of order depending on which buckets were excluded by the first shard to respond.
Depending on how many shards you have, it's fairly trivial to reproduce using bin/solr -e cloud and the exampledocs/*.xml files...
$ curl http://localhost:8983/solr/techproducts/select -d 'q=*:*&rows=0&wt=xml&json.facet={
foo:{ type:range, field:price, start:0, end:2000, gap:100, other:all, mincount:1} }'
<?xml version="1.0" encoding="UTF-8"?>
<response>
<lst name="responseHeader">
<bool name="zkConnected">true</bool>
<int name="status">0</int>
<int name="QTime">13</int>
<lst name="params">
<str name="q">*:*</str>
<str name="json.facet">{
foo:{ type:range, field:price, start:0, end:2000, gap:100, other:all, mincount:1} }</str>
<str name="rows">0</str>
<str name="wt">xml</str>
</lst>
</lst>
<result name="response" numFound="32" start="0" maxScore="1.0">
</result>
<lst name="facets">
<long name="count">32</long>
<lst name="foo">
<arr name="buckets">
<lst>
<float name="val">0.0</float>
<long name="count">7</long>
</lst>
<lst>
<float name="val">100.0</float>
<long name="count">2</long>
</lst>
<lst>
<float name="val">300.0</float>
<long name="count">3</long>
</lst>
<lst>
<float name="val">400.0</float>
<long name="count">1</long>
</lst>
<lst>
<float name="val">200.0</float>
<long name="count">1</long>
</lst>
<lst>
<float name="val">600.0</float>
<long name="count">1</long>
</lst>
</arr>
<lst name="before">
<long name="count">0</long>
</lst>
<lst name="after">
<long name="count">1</long>
</lst>
<lst name="between">
<long name="count">15</long>
</lst>
</lst>
</lst>
</response>