You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shawn Heisey <so...@elyograg.org> on 2012/06/10 12:36:50 UTC
SolrJ and Solr on different java versions
Because Java 6 is going EOL, we plan to upgrade to Java 7 at some point
in the next few months. In order to ensure that it goes smoothly, we
will only update one index at a time. This means that the SolrJ program
will be running on a different Java version than one of the indexes, and
the same version as the other index. We will also be upgrading the Java
version on our web servers that also use SolrJ, though that may happen
on an entirely different schedule.
Are the different Unicode versions between client and server going to be
an issue? Should we plan on testing everything behind the scenes and
then upgrading Java on everything at once (Solr, SolrJ, and the web
application) rather than trying to phase it in?
The data originates in a MySQL database. For performance reasons, we
use DIH to do full rebuilds, but all regular updating is done with
update requests in SolrJ. The two indexes are updated independent from
each other, but it is all done within one running copy of the program.
I asked this question on the user list before, but I don't remember
seeing an answer. The recent comment on LUCENE-2073 made it fresh in my
mind.
Thanks,
Shawn
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: SolrJ and Solr on different java versions
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Shawn Heisey [mailto:solr@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-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: SolrJ and Solr on different java versions
Posted by Shawn Heisey <so...@elyograg.org>.
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_MIGRATION.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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: SolrJ and Solr on different java versions
Posted by Robert Muir <rc...@gmail.com>.
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_MIGRATION.html
On Sun, Jun 10, 2012 at 6:36 AM, Shawn Heisey <so...@elyograg.org> wrote:
> Because Java 6 is going EOL, we plan to upgrade to Java 7 at some point in
> the next few months. In order to ensure that it goes smoothly, we will only
> update one index at a time. This means that the SolrJ program will be
> running on a different Java version than one of the indexes, and the same
> version as the other index. We will also be upgrading the Java version on
> our web servers that also use SolrJ, though that may happen on an entirely
> different schedule.
>
> Are the different Unicode versions between client and server going to be an
> issue? Should we plan on testing everything behind the scenes and then
> upgrading Java on everything at once (Solr, SolrJ, and the web application)
> rather than trying to phase it in?
>
> The data originates in a MySQL database. For performance reasons, we use
> DIH to do full rebuilds, but all regular updating is done with update
> requests in SolrJ. The two indexes are updated independent from each other,
> but it is all done within one running copy of the program.
>
> I asked this question on the user list before, but I don't remember seeing
> an answer. The recent comment on LUCENE-2073 made it fresh in my mind.
>
> Thanks,
> Shawn
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org