[
https://issues.apache.org/jira/browse/LUCENE-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122997#comment-14122997
]
Robert Muir commented on LUCENE-5925:
-------------------------------------
By the way, like the java apis, we can relax the requirements on the Directory
method:
* guarantee target will never exist
* we don't care about atomicity of "source" vs "dest", its fine if both exist
for a while, etc.
* don't require that "dest" is visible in listAll() on return, as long as
fsyncing the directory will make it so.
* ...
All we care about is the contents of "dest" appear atomic for read operations
against it.
> Use rename instead of segments_N fallback / segments.gen etc
> ------------------------------------------------------------
>
> Key: LUCENE-5925
> URL: https://issues.apache.org/jira/browse/LUCENE-5925
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Robert Muir
>
> Our commit logic is strange, we write corrupted commit points and only on the
> last phase of commit do we "correct them".
> This means the logic to get the latest commit is always scary and awkward,
> since it must deal with partial commits, and try to determine if it should
> fall back to segments_N-1 or actually relay an exception.
> This logic is incomplete/sheisty as we, e.g. i think we only fall back so far
> (at most one).
> If we somehow screw up in all this logic do the wrong thing, then we lose
> data (e.g. LUCENE-4870 wiped entire index because of TooManyOpenFiles).
> We now require java 7, i think we should expore instead writing
> {{pending_segments_N}} and then in finishCommit() doing an atomic rename to
> {{segments_N}}.
> We could then remove all the complex fallback logic completely, since we no
> longer have to deal with "ignoring partial commits", instead simply
> delivering any exception we get when trying to read the commit and sleep
> better at night.
> In java 7, we have the apis for this (ATOMIC_MOVE).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
