Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: pass (athena.apache.org: domain of solr@elyograg.org designates
 166.70.79.219 as permitted sender)
Message-ID: <4FD4F79D.4010707@elyograg.org>
Date: Sun, 10 Jun 2012 13:38:05 -0600
From: Shawn Heisey <solr@elyograg.org>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: dev@lucene.apache.org
Subject: Re: SolrJ and Solr on different java versions
References: <4FD478C2.8070804@elyograg.org>
 <CAOdYfZXq1D_8TjKr-aQTV8+P9QgaZ3rWU9Bpt_BR6jXDpxtouw@mail.gmail.com>
In-Reply-To: 
 <CAOdYfZXq1D_8TjKr-aQTV8+P9QgaZ3rWU9Bpt_BR6jXDpxtouw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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