lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael McCandless (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (LUCENE-6171) Make lucene completely write-once
Date Tue, 14 Jun 2016 19:28:08 GMT

     [ https://issues.apache.org/jira/browse/LUCENE-6171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Michael McCandless resolved LUCENE-6171.
----------------------------------------
       Resolution: Fixed
    Fix Version/s: 6.2
                   master (7.0)

> 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
>             Fix For: master (7.0), 6.2
>
>         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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message