You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Mark Miller (JIRA)" <ji...@apache.org> on 2018/05/08 05:06:00 UTC
[jira] [Commented] (SOLR-12321) Use of builtin java serialization
for admin response breaks 7.3 compatibility
[ https://issues.apache.org/jira/browse/SOLR-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16466871#comment-16466871 ]
Mark Miller commented on SOLR-12321:
------------------------------------
Yeah, this should have been done by serializing the response map itself with JavaBin or something. There is always a better option than built in Java serialization. I actually reviewed this and put it in way back, so it's my fault. We should have pulled the map from the object and serialized that with JavaBin or stored it as JSON or or or.
> Use of builtin java serialization for admin response breaks 7.3 compatibility
> -----------------------------------------------------------------------------
>
> Key: SOLR-12321
> URL: https://issues.apache.org/jira/browse/SOLR-12321
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 7.3, 7.3.1
> Reporter: Will Currie
> Priority: Minor
>
> Premise: During an upgrade I should be able to run a 7.3 pull replica against a 7.2 tlog leader. Or vice versa.
>
> Adding a new method[1] to SolrResponse has broken binary compatibility. When I try to register a new pull replica using the admin api[2] I get an HTTP 500 responseI see this error logged: java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse; local class incompatible: stream classdesc serialVersionUID = 3945300637328478755, local class serialVersionUID = -793110010336024264
>
> The replica actually seems to register ok it just can't read the response because the bytes from the 7.2 leader include a different serialVersionUID.
>
> Should SolrResponse include a serialVersionIUID? All subclasses too.
> [~markrmiller@gmail.com]'s advice is that the project should never use builtin java serialization.
>
> It looks like stock java serialization is only used for these admin responses. Query responses use JavaBinCodec instead..
>
> Full(ish) stack trace:
> {noformat}
> ERROR HttpSolrCall null:org.apache.solr.common.SolrException: java.io.InvalidClassException: org.apache.solr.client.solrj.SolrResponse; local class incompatible: st
> ream classdesc serialVersionUID = 3945300637328478755, local class serialVersionUID = -7931100103360242645
> at org.apache.solr.client.solrj.SolrResponse.deserialize(SolrResponse.java:73)
> at org.apache.solr.handler.admin.CollectionsHandler.sendToOCPQueue(CollectionsHandler.java:348)
> at org.apache.solr.handler.admin.CollectionsHandler.invokeAction(CollectionsHandler.java:256)
> at org.apache.solr.handler.admin.CollectionsHandler.handleRequestBody(CollectionsHandler.java:230)
> at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:195)
> at org.apache.solr.servlet.HttpSolrCall.handleAdmin(HttpSolrCall.java:736)
> at org.apache.solr.servlet.HttpSolrCall.handleAdminRequest(HttpSolrCall.java:717)
> at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:498)
> at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:384)
> at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:330)
> {noformat}
>
> [1] [https://github.com/apache/lucene-solr/commit/5ce83237e804ac1130eaf5cf793955667793fee0#diff-b809fa594f93aa6805381029a188e4e2R46]
> [2] [http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=blah&shard=shard1&node=blah&type=pull]
--
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