Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <1217905257.1203978411107.JavaMail.jira@brutus>
Date: Mon, 25 Feb 2008 14:26:51 -0800 (PST)
From: "Michael McCandless (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Commented: (LUCENE-1191) If IndexWriter hits
 OutOfMemoryError it should not commit
In-Reply-To: <1670694558.1203974811053.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/LUCENE-1191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12572277#action_12572277 ] 

Michael McCandless commented on LUCENE-1191:
--------------------------------------------

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!

> If IndexWriter hits OutOfMemoryError it should not commit
> ---------------------------------------------------------
>
>                 Key: LUCENE-1191
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1191
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Index
>    Affects Versions: 1.9, 2.0.0, 2.1, 2.2, 2.3, 2.3.1, 2.4
>            Reporter: Michael McCandless
>            Assignee: Michael McCandless
>            Priority: Minor
>             Fix For: 2.4
>
>         Attachments: LUCENE-1191.patch
>
>
> 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.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org