Yeah, I saw the change to flush(). Trying to work out the correct
strategy for our IndexWriter handling now. We probably should not be
using autocommit for our writers.
It was brought up by others that the OutOfMemoryError handling
requirements are a fairly strong part of the contract now - but aren't
documented. Do you think the last paragraph below should be incorporated
into the class JavaDoc?
cheers,
jed.
Michael McCandless wrote:
Sorry I forgot to follow up with the issue, but yup that's the one.
I did also fix IW to disallow flush after it has seen an OOME.
Mike
Jed Wesley-Smith wrote:
Michael,
https://issues.apache.org/jira/browse/LUCENE-1429
Thanks mate. I'll try and work out the client handling policy of the
IndexWriter calls. I see that flush now aborts the transaction as
well...
cheers,
jed.
Michael McCandless wrote:
Woops, you're right: this is a bug. I'll open an issue, fold in your
nice test case & fix it. Thanks Jed!
On hitting OOM, IndexWriter marks that its internal state (buffered
documents, deletions) may be corrupt and so it rollsback to the last
commit instead of flushing a new segment.
To workaround this, on catching an OOME on any of IndexWriter's
methods, you should 1) forcibly remove the write lock
(IndexWriter.unlock static method) and then 2) not call any methods on
the old writer. Even if the old writer has concurrent merges running,
they will refuse to commit on seeing that an OOM had occurred.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
