[ https://issues.apache.org/jira/browse/SOLR-7452?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16043394#comment-16043394 ]
Yonik Seeley commented on SOLR-7452: ------------------------------------ Actually, it looks like this is more the root-cause stack trace: {code} [junit4] 2> 708657 ERROR (qtp1112930155-8135) [n:127.0.0.1:36871_w_rb c:collection1 s:shard2 r:core_node1 x:collection1] o.a.s.c.s.i.s.ExceptionStream java.lang.ClassCastException: java.lang.Integer cannot be cast to java.lang.Long [junit4] 2> at org.apache.calcite.avatica.util.AbstractCursor$LongAccessor.getLong(AbstractCursor.java:540) [junit4] 2> at org.apache.calcite.avatica.AvaticaSite.get(AvaticaSite.java:305) [junit4] 2> at org.apache.calcite.avatica.AvaticaResultSet.getObject(AvaticaResultSet.java:393) [junit4] 2> at org.apache.solr.client.solrj.io.stream.JDBCStream$1.selectValue(JDBCStream.java:314) [junit4] 2> at org.apache.solr.client.solrj.io.stream.JDBCStream.read(JDBCStream.java:506) [junit4] 2> at org.apache.solr.handler.SQLHandler$SqlHandlerStream.read(SQLHandler.java:186) [junit4] 2> at org.apache.solr.client.solrj.io.stream.ExceptionStream.read(ExceptionStream.java:68) [junit4] 2> at org.apache.solr.handler.StreamHandler$TimerStream.read(StreamHandler.java:587) [junit4] 2> at org.apache.solr.client.solrj.io.stream.TupleStream.lambda$writeMap$0(TupleStream.java:87) [junit4] 2> at org.apache.solr.response.JSONWriter.writeIterator(JSONResponseWriter.java:523) [junit4] 2> at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:180) [junit4] 2> at org.apache.solr.response.JSONWriter$2.put(JSONResponseWriter.java:559) [junit4] 2> at org.apache.solr.client.solrj.io.stream.TupleStream.writeMap(TupleStream.java:84) [junit4] 2> at org.apache.solr.response.JSONWriter.writeMap(JSONResponseWriter.java:547) [junit4] 2> at org.apache.solr.response.TextResponseWriter.writeVal(TextResponseWriter.java:198) [junit4] 2> at org.apache.solr.response.JSONWriter.writeNamedListAsMapWithDups(JSONResponseWriter.java:209) [junit4] 2> at org.apache.solr.response.JSONWriter.writeNamedList(JSONResponseWriter.java:325) [junit4] 2> at org.apache.solr.response.JSONWriter.writeResponse(JSONResponseWriter.java:120) [junit4] 2> at org.apache.solr.response.JSONResponseWriter.write(JSONResponseWriter.java:71) [junit4] 2> at org.apache.solr.response.QueryResponseWriterUtil.writeQueryResponse(QueryResponseWriterUtil.java:65) {code} The facet labels from faceting on an int field were sometimes returning Long, which led to merging issues. The patch corrected that, so now Integer labels are returned. {code} --- a/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java +++ b/solr/core/src/java/org/apache/solr/search/facet/FacetRange.java @@ -533,6 +533,10 @@ class FacetRangeProcessor extends FacetProcessor<FacetRange> { public IntCalc(final SchemaField f) { super(f); } @Override + public Comparable bitsToValue(long bits) { + return (int)bits; + } + @Override {code} So it looks like we need AvaticaResultSet to use to use AbstractCursor$LongAccessor@IntAccessor rather than a AbstractCursor$LongAccessor. I'm not sure where that mapping is set up though... > json facet api returning inconsistent counts in cloud set up > ------------------------------------------------------------ > > Key: SOLR-7452 > URL: https://issues.apache.org/jira/browse/SOLR-7452 > Project: Solr > Issue Type: Bug > Components: Facet Module > Affects Versions: 5.1 > Reporter: Vamsi Krishna D > Labels: count, facet, sort > Attachments: SOLR-7452.patch, SOLR-7452.patch, SOLR-7452.patch > > Original Estimate: 96h > Remaining Estimate: 96h > > While using the newly added feature of json term facet api > (http://yonik.com/json-facet-api/#TermsFacet) I am encountering inconsistent > returns of counts of faceted value ( Note I am running on a cloud mode of > solr). For example consider that i have txns_id(unique field or key), > consumer_number and amount. Now for a 10 million such records , lets say i > query for > q=*:*&rows=0& > json.facet={ > biskatoo:{ > type : terms, > field : consumer_number, > limit : 20, > sort : {y:desc}, > numBuckets : true, > facet:{ > y : "sum(amount)" > } > } > } > the results are as follows ( some are omitted ): > "facets":{ > "count":6641277, > "biskatoo":{ > "numBuckets":3112708, > "buckets":[{ > "val":"surya", > "count":4, > "y":2.264506}, > { > "val":"raghu", > "COUNT":3, // capitalised for recognition > "y":1.8}, > { > "val":"malli", > "count":4, > "y":1.78}]}}} > but if i restrict the query to > q=consumer_number:raghu&rows=0& > json.facet={ > biskatoo:{ > type : terms, > field : consumer_number, > limit : 20, > sort : {y:desc}, > numBuckets : true, > facet:{ > y : "sum(amount)" > } > } > } > i get : > "facets":{ > "count":4, > "biskatoo":{ > "numBuckets":1, > "buckets":[{ > "val":"raghu", > "COUNT":4, > "y":2429708.24}]}}} > One can see the count results are inconsistent ( and I found many occasions > of inconsistencies). > I have tried the patch https://issues.apache.org/jira/browse/SOLR-7412 but > still the issue seems not resolved -- This message was sent by Atlassian JIRA (v6.3.15#6346) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org