[
https://issues.apache.org/jira/browse/LUCENE-8149?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16352801#comment-16352801
]
ASF subversion and git services commented on LUCENE-8149:
---------------------------------------------------------
Commit 709c7f081245ed56aaa5e7176d8f44c7d3dcb1c4 in lucene-solr's branch
refs/heads/branch_7x from Erick Erickson
[ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=709c7f0 ]
LUCENE-8149: NRTCachingDirectory does not need to preemptively delete segment
files and generate exceptions
(cherry picked from commit 4bd4972)
> NRTCachingDirectory does not need to preemptively delete segment files and
> generate exceptions
> ----------------------------------------------------------------------------------------------
>
> 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]
