[
https://issues.apache.org/jira/browse/SOLR-12321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16467382#comment-16467382
]
Jan Høydahl commented on SOLR-12321:
------------------------------------
Something to add to invalid API checks?
Hmm, this is what we have {{version}} request parameter for, isn't it?
{noformat}
(org.apache.solr.common.params.CommonParams)
/** version parameter to check request-response compatibility */
String VERSION ="version";{noformat}
What if we bump request version from 2.2 to 2.3 in a bugfix 7.3.2 release which
also switches to JavaBin serialization. Then we have a mechanism for server to
serve different response to a 2.3 client than a 2.2 client.
After that we could release a 7.2.2 release with ability to serve either Java
or Javabin serialised SolrResponse depending on version param. In case of
serialised object stored in Blob/ZK, the version may be lost so a fallback
parsing may be necessary?
> 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.
> [[email protected]]'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: [email protected]
For additional commands, e-mail: [email protected]
