[
https://issues.apache.org/jira/browse/LUCENE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16351428#comment-16351428
]
Erick Erickson commented on LUCENE-8149:
----------------------------------------
So here's what the patch looks like. All tests pass.
Also, based on Adrien's comment I decided to just go with it for a test. So
over last night I ran a test that randomly killed one of 4 jvms while indexing
on the theory that if the preemptive deletes were cleaning up after some kind
of anomaly it might trigger and it was fine.
I'll look this over to get a better understanding of the code, but are people
OK with this approach?
> Document why NRTCachingDirectory needs to preemptively delete segment files.
> ----------------------------------------------------------------------------
>
> Key: LUCENE-8149
> URL: https://issues.apache.org/jira/browse/LUCENE-8149
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Minor
> Attachments: LUCENE-8149.patch
>
>
> Moving over here from SOLR-11892. After getting through my confusion I've
> found the following: NRTCachingDirectory.createOutput tries to delete segment
> files before creating them. We should at least add a bit of commentary as to
> what the pre-emptive delete is there for since on the surface it's not
> obvious.
> try {
> in.deleteFile(name);
> {{ } catch (IOException ioe) {}}
> // This is fine: file may not exist
> {{ }}}
> If I change to using MMapDirectory or NIOFSDirectory these exceptions are not
> thrown. What's special about NRTCachingDirectory that it needs this when two
> of the possible underlying FS implementations apparently do not? Or is this
> necessary for, say, Windows or file systems than the two I tried? Or is it
> some interaction between the RAM based segments and segments on disk?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
