Uploaded image for project: 'Lucene - Core'
  1. Lucene - Core
  2. LUCENE-1191

If IndexWriter hits OutOfMemoryError it should not commit

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • 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
    • Component/s: core/index
    • Labels:
      None
    • Lucene Fields:
      New

      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.

      1. LUCENE-1191.patch
        26 kB
        Michael McCandless

        Activity

        Hide
        karl.wettin Karl Wettin added a comment -

        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 + " )");
        
        Show
        karl.wettin Karl Wettin added a comment - 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 + " )" );
        Hide
        mikemccand Michael McCandless added a comment -

        Karl, was that with trunk, 2.3.0 or 2.3.1?

        Show
        mikemccand Michael McCandless added a comment - Karl, was that with trunk, 2.3.0 or 2.3.1?
        Hide
        karl.wettin Karl Wettin added a comment -

        2.3.0

        Show
        karl.wettin Karl Wettin added a comment - 2.3.0
        Hide
        mikemccand Michael McCandless added a comment -

        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!

        Show
        mikemccand Michael McCandless added a comment - 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!
        Hide
        hossman Hoss Man added a comment -

        targeted for 2.3.2 bug fix release

        Show
        hossman Hoss Man added a comment - targeted for 2.3.2 bug fix release

          People

          • Assignee:
            mikemccand Michael McCandless
            Reporter:
            mikemccand Michael McCandless
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development