Mark Lassau wrote:
Mike,
Thanks for the prompt response.
Michael McCandless wrote:
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!
... and we love Lucene :)
Glad to hear it!
<snip>
I would think LUCENE-1044 (not corrupting search index if OS or
machine crashes) is important for Atlassian.
LUCENE-1044 is only marked as fixed in v2.4
I assumed that the possible corruption on hard shutdown existed in
v2.2.0 (and earlier), so we are no worse off by upgrading to v2.3.2.
Is that the case?
That's right.
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).
Thanks, I read those. Good job on providing a very useful change
summary.
However, I guess I was also interested in any reports "from the
field". Sometimes there can be unexpected consequences.
eg, I read somewhere of one user having multi-threaded issues
because of a change from Vector to ArrayList in some implementation.
OK gotchya.
I think that particular change was to Document (in how it stores
fields internally); there was a case where someone was actually adding
fields to a document with multiple threads and the switch to ArrayList
broke that code. It's tricky because Document never declared that its
APIs were thread safe.
Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]