lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Uwe Schindler" <>
Subject RE: SolrJ and Solr on different java versions
Date Sun, 10 Jun 2012 20:47:41 GMT
Hi Shawn,

It is correct, the JRE_VERSION_MIGRATION.txt / .html (in trunk/4.0) is about Lucene and Indexing.
In fact, the changes in Unicode versions affecting analysis (as this guide describes). SolrJ
does not do any analysis, is just passes the String/native types down to solr uon the wire.
SolrJ is here not different to any other client library like those from PHP or Python talking
to Solr. If changes in Unicode version would change the public API of Solr, there would be
a bug. The only things in the public API of Solr (the one SolrJ uses) are de/encoding of Unicode
codepoints to bytes that go over the wire. And that does not change between those Unicode
versions for the used character sets like UTF-8.

- If you migrate the Java version in the client -> don't care (like for any other language
used in the client). As long as there are no charset encoding bugs you are fine
- If you migrate the Java version on the Solr server -> reindex, as analysisis components
may behave different (lowercasing,...)


Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen

> -----Original Message-----
> From: Shawn Heisey []
> Sent: Sunday, June 10, 2012 9:38 PM
> To:
> Subject: Re: SolrJ and Solr on different java versions
> On 6/10/2012 5:59 AM, Robert Muir wrote:
> > There is a text file explaining this: JRE_VERSION_MIGRATION.txt
> >
> > here is a link to the one from the latest nightly build:
> >
> > ON.html
> I've seen that already.  That tells me that I should not run code that creates the
> index (index analyzers) and code that searches the index (query analyzers) on
> different Java versions.  Both of these activities take place within Solr itself,
> there is no discussion of the SolrJ client.  Currently my SolrJ indexing code just
> grabs data from MySQL (utf8), assigns it to the correct type of Java primitive or
> object, and passes it in an update request.  There is no text manipulation.  Even
> if I add such manipulation in the future, I would imagine that it will only be
> string splitting on delimiters within the ASCII character set.
> When I actually do the upgrade on Solr, I will reindex.  There is no replication;
> the indexing code knows about both distributed indexes and operates on them
> independently.
> My concern is about SolrJ being on one java version while Solr is on another.
> The SolrJ indexing code will probably be upgraded to Java 7 first.  As that code
> normally runs on the first Solr chain A server (corosync/pacemaker prefers that
> server, but can run it on any Solr server), Solr chain A would get upgraded (and
> reindexed) at the same time.  This is the first mismatch - the SolrJ indexing
> code would be running on Java 7, index chain B would be running on Java 6.
> Assuming no failures, my haproxy load balancer can keep chain A in a backup
> role until such time as the website (SolrJ queries) is upgraded, after which I
> would upgrade chain B.  It would be nice if I could get chain B upgraded before
> the website, since I think the website will take the longest to get through QA.
> The website is a tomcat cluster that I don't administer.  If it's possible to
> upgrade those servers one at a time, I imagine that it will be done that way.
> Do you anticipate any problems with that java upgrade sequence?
> Thanks,
> Shawn
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: For additional
> commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message