[
https://issues.apache.org/jira/browse/SOLR-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13139522#comment-13139522
]
Mike Sokolov commented on SOLR-2204:
------------------------------------
bq. a) Would there be a more robust way of detecting version mismatch than
parsing text from the exception? Perhaps a new Solr specific exception with a
version variable?
I'm not sure how this can be done since there is no way to reach back in time
and modify the installed base of older servers.
bq. b) HTTP request param "version" is currently 2.2, even for Solr3.4. The
patch changes this to 3.4. Should not the version instead be bumped to 2.3, or
should we let it follow solr versions (which is less confusing in many cases..)?
I think I agree that tracking the Solr version makes the most sense here -
maybe it would prove useful to know that even if the binary format doesn't
change from release to release. Other things might?
bq. c) How would the new SolrJ version handle talking to 1.4 server? Is there a
way to force a new SolrJ to start talking v1 instead of fallback?
Yes the patch only provides a mechanism for forcing the use of v1 on the server
(using a parameter in solrconfig.xml), which was really only designed for
testing. I was attempting to make minimal changes.
But it does makes sense to provide a means to force a protocol version in
production environments (to avoid fallback), and probably the API should allow
specifying the version, rather than just having a "forceVersion1" method, as
the patch has. I think this would require adding a "setJavabinVersion()" to
CommonsHTTPSolrServer (and/or SolrServer), BinaryResponseWriter and
BinaryRequestWriter.
> Cross-version replication broken by new javabin format
> ------------------------------------------------------
>
> Key: SOLR-2204
> URL: https://issues.apache.org/jira/browse/SOLR-2204
> Project: Solr
> Issue Type: Bug
> Components: replication (java)
> Affects Versions: 3.1
> Environment: Linux idxst0-a 2.6.18-194.3.1.el5.centos.plusxen #1 SMP
> Wed May 19 09:59:34 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux
> java version "1.6.0_20"
> Java(TM) SE Runtime Environment (build 1.6.0_20-b02)
> Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode)
> Reporter: Shawn Heisey
> Fix For: 3.5, 4.0
>
> Attachments: SOLR-2204.patch, SOLR-2204.patch
>
>
> Slave server is branch_3x, revision 1027974. Master server is 1.4.1.
> Replication fails because of the new javabin format.
> SEVERE: Master at: http://HOST:8983/solr/live/replication is not available.
> Index fetch failed. Exception: Invalid version or the data in not in
> 'javabin' format
> Switching Solr's internally generated requests to XML, or adding support for
> both javabin versions would get rid of this problem. I do not know how to do
> either of these things.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
