[
https://issues.apache.org/jira/browse/LUCENE-5574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13960006#comment-13960006
]
Michael McCandless commented on LUCENE-5574:
--------------------------------------------
I think we should remove IW.deletePendingFiles from
StandardDirectoryReader.close: the less the IR does with deleting files on
close the better!
But we cannot remove the incRef/decRef unless we want to revert LUCENE-5434, ie
stop protecting the files referenced by opened NRT readers from deletion. So
leave that for now.
On MDW, I think we could do a middle ground: it should only complain about
unref'd files that nobody had previously tried to delete. I think this will 1)
let us leave this checking on by default, and 2) should still catch bugs in IFD
where it caused IW not to attempt deletion of files that it should have.
> NRT Reader close can wipe index it doesn't own
> ----------------------------------------------
>
> Key: LUCENE-5574
> URL: https://issues.apache.org/jira/browse/LUCENE-5574
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Affects Versions: 4.8, 5.0, 4.7.1
> Reporter: Simon Willnauer
> Priority: Critical
> Fix For: 4.8, 5.0, 4.7.2
>
> Attachments: LUCENE-5574.patch, LUCENE-5574.patch, LUCENE-5574.patch
>
>
> Today NRT Readers try to clean up unused files via their IW reference when
> they are closed. Yet, if the index writer is already closed another index
> could have been created on the same directory which can create the same files
> as the IW before. For the NRT Reader those files are not referenced and it
> will simply wipe them away. If you use this in a replication scenario where
> directories are reused this can simply wipe your index away or in combination
> with the FSync issue LUCENE-5570 create 0-byte files. I have a test that
> reproduces this issue
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
