Lucene - Core
  1. Lucene - Core
  2. LUCENE-1191

If IndexWriter hits OutOfMemoryError it should not commit

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor 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

        Michael McCandless created issue -
        Michael McCandless made changes -
        Field Original Value New Value
        Attachment LUCENE-1191.patch [ 12376444 ]
        Hide
        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 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
        Michael McCandless added a comment -

        Karl, was that with trunk, 2.3.0 or 2.3.1?

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

        2.3.0

        Show
        Karl Wettin added a comment - 2.3.0
        Hide
        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
        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!
        Michael McCandless made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Hoss Man added a comment -

        targeted for 2.3.2 bug fix release

        Show
        Hoss Man added a comment - targeted for 2.3.2 bug fix release
        Hoss Man made changes -
        Fix Version/s 2.3.2 [ 12313057 ]
        Michael Busch made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Mark Thomas made changes -
        Workflow jira [ 12424424 ] Default workflow, editable Closed status [ 12561828 ]
        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12561828 ] jira [ 12582898 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development