[
https://issues.apache.org/jira/browse/LUCENE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16349708#comment-16349708
]
Erick Erickson commented on LUCENE-8149:
----------------------------------------
FWIW, simply taking that code out passes all the test suite. What I have _not_
tested is things like killing Solr while actively indexing and the like. I'll
be able to do some of that ad-hoc type testing Friday....
> 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
>
> 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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
