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