[
https://issues.apache.org/jira/browse/LUCENE-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122966#comment-14122966
]
Robert Muir commented on LUCENE-5925:
-------------------------------------
yes. the main thing it doesnt guarantee is atomic replacement, but we don't
need that:
http://docs.oracle.com/javase/7/docs/api/java/nio/file/Files.html#move%28java.nio.file.Path,%20java.nio.file.Path,%20java.nio.file.CopyOption...%29
> 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]
