If IndexWriter hits OutOfMemoryError it should not commit

• Key: LUCENE-1191
• Type: Improvement
• Status: Closed
• Resolution: Fixed
• Priority: Minor
• Assignee: Michael McCandless
• Reporter: Michael McCandless
• Component/s: Index
• Affects Version/s: 1.9, 2.0.0, 2.1, 2.2, 2.3, 2.3.1, 2.4
• Fix Version/s: 2.3.2, 2.4

Description

While progress has been made making IndexWriter robust to OOME, I
think there is still a real risk that an OOME at a bad time could put
IndexWriter into a bad state such that if close() is called and
somehow it succeeds without hitting another OOME, it risks
introducing messing up the index.

I'd like to detect if OOME has been hit in any of the methods that
alter IW's state, and if so, do not commit changes to the index. If
close is called after hitting OOME, I think writer should instead
abort.

Attached patch just adds try/catch clauses to catch OOME, note that
it was hit, and re-throw it. Then, sync() refuses to commit a new
segments_N if OOME was hit, and close instead calls abort when OOME
was hit. All tests pass. I plan to commit in a day or two.

Comments

I think I hit that problem this weekend. One of my writer threads died due to an OOME, but the other threads kept going as memory was released from the dying thread. I then hit this SegmentMerger#appendPostings exception each flush:

if (doc < 0 || (df > 0 && doc <= lastDoc))
          throw new CorruptIndexException("docs out of order (" + doc +
              " <= " + lastDoc + " )");

[Michael McCandless]

Karl, was that with trunk, 2.3.0 or 2.3.1?

[Karl Wettin]

2.3.0

[Michael McCandless]

OK. LUCENE-1171 fixed certain OOM cases after 2.3.0, and was backported to 2.3.1, and it may have fixed this although I didn't think there were cases that would lead to corruption of the posting lists. If you also see this happen on 2.3.1 please report back!

[Hoss Man]

targeted for 2.3.2 bug fix release