lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Sokolov (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-2204) Cross-version replication broken by new javabin format
Date Tue, 06 Sep 2011 01:11:09 GMT

    [ 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message