Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Fri, 28 Oct 2011 16:21:32 +0000 (UTC)
From: =?utf-8?Q?Jan_H=C3=B8ydahl_=28Commented=29_=28JIRA=29?=
 <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <1730502032.32101.1319818892210.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <17633464.111151288231279229.JavaMail.jira@thor>
Subject: [jira] [Commented] (SOLR-2204) Cross-version replication broken by
 new javabin format
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


    [ https://issues.apache.org/jira/browse/SOLR-2204?page=3Dcom.atlassian.=
jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D13138=
492#comment-13138492 ]=20

Jan H=C3=B8ydahl commented on SOLR-2204:
-----------------------------------

I now have a customer facing this very problem, but in another context than=
 replication.

The case is that they use Escenic ECM system (http://en.wikipedia.org/wiki/=
Escenic) which is Java based and from version 5 they also have their own bu=
ilt-in Solr search, on version 1.4.

The online newspaper publications run in the same JVM and then there is a c=
lash between SolrJ versions needed for the built-in editorial search and th=
e enduser-facing search. Thus it would be ideal if we could do a drop-in up=
grade to solrj3.x without breaking the internal search of Escenic (which al=
so uses JavaBin of course).

I'll consider committing this, but first it needs some more work I guess.

a) Would there be a more robust way of detecting version mismatch than pars=
ing text from the exception? Perhaps a new Solr specific exception with a v=
ersion variable?
b) HTTP request param "version" is currently 2.2, even for Solr3.4. The pat=
ch 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 cas=
es..)?
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?
               =20
> 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.  Re=
plication fails because of the new javabin format.
> SEVERE: Master at: http://HOST:8983/solr/live/replication is not availabl=
e. Index fetch failed. Exception: Invalid version or the data in not in 'ja=
vabin' 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 administrato=
rs: https://issues.apache.org/jira/secure/ContactAdministrators!default.jsp=
a
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