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 ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Shawn Heisey [mailto:s...@elyograg.org] > Sent: Sunday, June 10, 2012 9:38 PM > To: dev@lucene.apache.org > 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: > > https://builds.apache.org/job/Lucene-trunk/javadoc/JRE_VERSION_MIGRATI > > 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: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
