[ https://issues.apache.org/jira/browse/LUCENE-5263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794024#comment-13794024 ]
ASF subversion and git services commented on LUCENE-5263: --------------------------------------------------------- Commit 1531836 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1531836 ] LUCENE-5263: if merge hits exc when releasing merged reader then drop changes and remove it from the pool, since the merge will be aborted > Deletes may be silently lost if an IOException is hit and later not hit > (e.g., disk fills up and then frees up) > --------------------------------------------------------------------------------------------------------------- > > Key: LUCENE-5263 > URL: https://issues.apache.org/jira/browse/LUCENE-5263 > Project: Lucene - Core > Issue Type: Bug > Components: core/index > Reporter: Michael McCandless > Assignee: Michael McCandless > Fix For: 4.5.1, 4.6, 5.0 > > Attachments: LUCENE-5263.patch, LUCENE-5263.patch > > > This case is tricky to handle, yet I think realistic: disk fills up > temporarily, causes an exception in writeLiveDocs, and then the app > keeps using the IW instance. > Meanwhile disk later frees up again, IW is closed "successfully". In > certain cases, we can silently lose deletes in this case. > I had already committed > TestIndexWriterDeletes.testNoLostDeletesOnDiskFull, and Jenkins seems > happy with it so far, but when I added fangs to the test (cutover to > RandomIndexWriter from IndexWriter, allow IOE during getReader, add > randomness to when exc is thrown, etc.), it uncovered some real/nasty > bugs: > * ReaderPool.dropAll was suppressing any exception it hit, because > {code}if (priorE != null){code} should instead be {code}if (priorE == > null){code} > * After a merge, we have to write deletes before committing the > segment, because an exception when writing deletes means we need > to abort the merge > * Several places that were directly calling deleter.checkpoint must > also increment the changeCount else on close IW thinks there are > no changes and doesn't write a new segments file. > * closeInternal was dropping pooled readers after writing the > segments file, which would lose deletes still buffered due to a > previous exc. -- This message was sent by Atlassian JIRA (v6.1#6144) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org