[
https://issues.apache.org/jira/browse/LUCENE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15329360#comment-15329360
]
Robert Muir commented on LUCENE-6171:
-------------------------------------
+1. This part of the change speaks volumes:
{noformat}
public FSIndexOutput(String name) throws IOException {
- this(name, StandardOpenOption.CREATE,
StandardOpenOption.TRUNCATE_EXISTING, StandardOpenOption.WRITE);
+ this(name, StandardOpenOption.WRITE, StandardOpenOption.CREATE_NEW);
}
{noformat}
Some of the issues i mentioned may have been resolved already? This issue is
quite old. I think many of these problems have been addressed since then.
> Make lucene completely write-once
> ---------------------------------
>
> Key: LUCENE-6171
> URL: https://issues.apache.org/jira/browse/LUCENE-6171
> Project: Lucene - Core
> Issue Type: Bug
> Reporter: Robert Muir
> Assignee: Michael McCandless
> Attachments: LUCENE-6171.patch
>
>
> Today, lucene is mostly write-once, but not always, and these are just very
> exceptional cases.
> This is an invitation for exceptional bugs: (and we have occasional test
> failures when doing "no-wait close" because of this).
> I would prefer it if we didn't try to delete files before we open them for
> write, and if we opened them with the CREATE_NEW option by default to throw
> an exception, if the file already exists.
> The trickier parts of the change are going to be IndexFileDeleter and
> exceptions on merge / CFS construction logic.
> Overall for IndexFileDeleter I think the least invasive option might be to
> only delete files older than the current commit point? This will ensure that
> inflateGens() always avoids trying to overwrite any files that were from an
> aborted segment.
> For CFS construction/exceptions on merge, we really need to remove the custom
> "sniping" of index files there and let only IndexFileDeleter delete files. My
> previous failed approach involved always consistently using
> TrackingDirectoryWrapper, but it failed, and only in backwards compatibility
> tests, because of LUCENE-6146 (but i could never figure that out). I am
> hoping this time I will be successful :)
> Longer term we should think about more simplifications, progress has been
> made on LUCENE-5987, but I think overall we still try to be a superhero for
> exceptions on merge?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
