[
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
