[
https://issues.apache.org/jira/browse/SOLR-2204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13097676#comment-13097676
]
Mike Sokolov commented on SOLR-2204:
------------------------------------
I'm posting a more fully-realized patch now. This is an important issue for
us, not just because of replication, but also because we may support a bunch of
different apps on a single server, would like to upgrade such a server, but
can't upgrade all the apps at once. Some might be stuck on an old version for
some time since we are locked into our client's update schedules. We could set
up old and new servers and migrate the apps one by one, but it just seemed to
me that the flexibility of being able to mix versions was worth some degree of
pain.
This patch restores support for version 1 utf-8 encoding to JavaBinCodec to be
used as a fallback when communicating with older peers.
When a v2 server detects a v1 client, it responds using v1. The javabin version
is inferred from the version byte read when unmarshalling binary content.
However, non-update requests won't have any such version info, so I increased
the version passed on every HTTP request, from 2.2 to 3.4 and also use this
string to detect older peers. I may have missed the significance of this value
and broken something else: wiser heads, please review!
The SolrJ client behaves a bit differently since it has no way of knowing in
advance what version the server is. With this patch, v2 clients detect a
version mismatch error by parsing the HTTP response text, retry and then fall
back to v1 for all future requests by recording the server javabin version in
the RequestWriter.
Testing this requires simulating the old behavior (ie forcing either the client
or server into v1 mode). To do this via jetty seemed to require a built-in
hook (in BinaryUpdateRequestHandler) for that, used only for testing, which
would be nice to avoid, but I didn't see how. Also - JettySolrRunner offers a
configfile param, but it didn't seem to have any effect, so I added a check for
the system property in CoreContainer, but maybe I missed something and there is
a better way to do this.
> 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.4, 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
