lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <j...@apache.org>
Subject [jira] [Created] (SOLR-13471) javabin codec can marshal data that it can't unmarshal (ClassCastException: class java.lang.Boolean cannot be cast to class java.lang.String)
Date Tue, 14 May 2019 21:36:00 GMT
Hoss Man created SOLR-13471:
-------------------------------

             Summary: javabin codec can marshal data that it can't unmarshal (ClassCastException:
class java.lang.Boolean cannot be cast to class java.lang.String)
                 Key: SOLR-13471
                 URL: https://issues.apache.org/jira/browse/SOLR-13471
             Project: Solr
          Issue Type: Bug
      Security Level: Public (Default Security Level. Issues are Public)
            Reporter: Hoss Man


I haven't dug into this, or been able to reproduce it (let alone get any additional logging/debugging/breakpoint
info) but in a few very sporadic, very rare, instances of running TestReplicationHandlerDiskOverFlow,
I triggered ClassCastException's in JavaBinCodec unmarshal code -- indicating that there is
some disconnect in expectations between the marshal & unmarshal code paths...

{noformat}
   [junit4]   2> 13342 ERROR (Thread-19) [    ] o.a.s.h.TestReplicationHandlerDiskOverFlow
Query Thread Failure
   [junit4]   2>           => org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
Error from server at http://127.0.0.1:54505/solr/collection1: class java.lang.Boolean cannot
be cast to class java.lang.String (java.lang.Boolean and java.lang.String are in module java.base
of loader 'bootstrap')
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:622)
   [junit4]   2> org.apache.solr.client.solrj.impl.HttpSolrClient$RemoteSolrException:
Error from server at http://127.0.0.1:54505/solr/collection1: class java.lang.Boolean cannot
be cast to class java.lang.String (java.lang.Boolean and java.lang.String are in module java.base
of loader 'bootstrap')
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:622)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:255)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.HttpSolrClient.request(HttpSolrClient.java:244)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.SolrRequest.process(SolrRequest.java:207)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:987)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.SolrClient.query(SolrClient.java:1002)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.handler.TestReplicationHandlerDiskOverFlow.lambda$testDiskOverFlow$1(TestReplicationHandlerDiskOverFlow.java:154)
~[test/:?]
   [junit4]   2> 	at java.lang.Thread.run(Thread.java:834) [?:?]
   [junit4]   2> Caused by: java.lang.ClassCastException: class java.lang.Boolean cannot
be cast to class java.lang.String (java.lang.Boolean and java.lang.String are in module java.base
of loader 'bootstrap')
   [junit4]   2> 	at org.apache.solr.common.util.JavaBinCodec.readOrderedMap(JavaBinCodec.java:223)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.common.util.JavaBinCodec.readObject(JavaBinCodec.java:298)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:280)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:193)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:50)
~[java/:?]
   [junit4]   2> 	at org.apache.solr.client.solrj.impl.HttpSolrClient.executeMethod(HttpSolrClient.java:620)
~[java/:?]
   [junit4]   2> 	... 7 more
 
{noformat}

It's possible that something about the test code (or code being tested) is doing something
it should not be doing, and adding something "unexpeted" to the response object -- but either
the unmarshal code needs to be _as forgiving_ as marshal code, or the marshal code should
fail fast -- not produce a binary stream that the unmarshal code can't parse.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message