[
https://issues.apache.org/jira/browse/LUCENE-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14123001#comment-14123001
]
Shai Erera commented on LUCENE-5925:
------------------------------------
bq. You would get an exception. So it needs to be supported.
What do you mean? We will no longer support indexing on FileSystems that don't
support atomic-move?
> 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]
