[ https://issues.apache.org/jira/browse/LUCENE-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12873409#action_12873409 ]
Uwe Schindler commented on LUCENE-2476: --------------------------------------- Merged to 2.9 revision: 949507 > Constructor of IndexWriter let's runtime exceptions pop up, while keeping the > writeLock obtained > ------------------------------------------------------------------------------------------------ > > Key: LUCENE-2476 > URL: https://issues.apache.org/jira/browse/LUCENE-2476 > Project: Lucene - Java > Issue Type: Bug > Components: Store > Affects Versions: 3.0.1 > Reporter: Cservenak, Tamas > Assignee: Michael McCandless > Priority: Blocker > Fix For: 2.9.3, 3.0.2, 3.1, 4.0 > > Attachments: LUCENE-2476.patch > > > Constructor of IndexWriter let's runtime exceptions pop up, while keeping the > writeLock obtained. > The init method in IndexWriter catches IOException only (I got > NegativeArraySize by reading up a _corrupt_ index), and now, there is no way > to recover, since the writeLock will be kept obtained. Moreover, I don't have > IndexWriter instance either, to "grab" the lock somehow, since the init() > method is called from IndexWriter constructor. > Either broaden the catch to all exceptions, or at least provide some > circumvention to clear up. In my case, I'd like to "fallback", just delete > the corrupted index from disk and recreate it, but it is impossible, since > the LOCK_HELD NativeFSLockFactory's entry about obtained WriteLock is _never_ > cleaned out and is no (at least apparent) way to clean it out forcibly. I > can't create new IndexWriter, since it will always fail with > LockObtainFailedException. -- 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org