Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <29182851-763C-4945-9BF8-D3E1E54D6DAA@mikemccandless.com>
From: Michael McCandless <lucene@mikemccandless.com>
To: java-user@lucene.apache.org
In-Reply-To: <48B3AE1C.7050209@atlassian.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v926)
Subject: Re: Upgrading from v2.2.0 to v2.3.2
Date: Tue, 26 Aug 2008 05:12:50 -0400
References: <48B3AE1C.7050209@atlassian.com>


Mark Lassau wrote:

> I am a developer on the JIRA Issue tracker, and we are considering  
> upgrading our Lucene version from v2.2.0 to v2.3.2.
> I have been charged with doing the risk analysis, and project work.
>
> I have read the change lists, and the bugs reported on the Lucene  
> Issue Tracker (JIRA of course ;), and some of the archived messages  
> on the Lucene lists.

We love Jira -- thanks!

> From this I would conclude that Lucene v2.3.2 has many performance  
> improvements as well as some other compelling enhancements and bug  
> fixes.
> However there also appear to be a number of issues introduced in  
> v2.3.x, not all of which are fixed in v2.3.2
> These include:
> * LUCENE-1335  Correctly handle concurrent calls to addIndexes,  
> optimize, commit
> I assume that if the application code doesn't make concurrent calls  
> to Lucene objects, or synchronises correctly then this will be OK.

That's the right workaround.  Also, commit() isn't available in 2.3,  
but the issue still applies to close(), rollback(), addIndexes() and  
optimize() in 2.3.

> * LUCENE-1175 occasional MergeException while indexing
> (can occur under load)
> This bug seems to be RAMDirectory-specific, and it is not clear  
> whether it was released or not.

Wasn't released, and wasn't RAMDirectory specific.

> * There seem to have been some issues with using autoCommit(false).
> Are these all fixed in v2.3.2?

To my knowledge, yes.

> Would it be recommended to use autoCommit(true) to be extra safe?

Well... autoCommit=true is going away in 3.0.  You should also see  
better performance with autoCommit=false.  And autoCommit=false also  
has nice transactional behavior (you have full control over when the  
changes are committed to the index).

> In addition is the following trap for young players:
> * LUCENE-1282 Sun hotspot compiler bug in 1.6.0_04/05 affects Lucene
> This is a bug in Sun JDK 6. Fixed in JDK 6 Update 10 (b28).
> The application developer needs to take steps to ensure that a  
> broken Sun JDK 6 is not used.

We also committed a workaround to Lucene for this JRE bug, which  
should allow you to use the buggy JRE releases, *but* it's not certain  
the workaround will alway sork.  I just experimented empirically until  
I found code that seemed to avoid the error.  It's by far safest to  
use a JRE that actually fixes the bug.

> I would really appreciate any comments on the overall stability of  
> v2.3.2 compared to v2.2.0, as well as any pointers about any  
> pitfalls to look out for on upgrade.
> For instance, although the message signatures of the API may be  
> backwardly compatible, it could be that some behaviour has changed  
> in a significant way.

I would think LUCENE-1044 (not corrupting search index if OS or  
machine crashes) is important for Atlassian.

The CHANGES.txt should be a reliable list of any non-backwards- 
compatible changes and how to revert to the old behavior (and if it  
isn't we'd love to hear about that!).  EG merging is now done  
concurrently by default, flushing is by RAM usage not doc count, merge  
selection is by size-in-bytes of each segment (not size-in-doc-count).

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org