[ 
https://issues.apache.org/jira/browse/LUCENE-5925?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14122972#comment-14122972
 ] 

Uwe Schindler commented on LUCENE-5925:
---------------------------------------

bq.  Does that cause the ATOMIC_MOVE to fail?

Yes it could in windows. But this would not be bad, it just fails the commit. 
You get Exception and all is fine, no corrumption.
As we never move to an already existing file or different file system, atomic 
moves should always work.

> 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]

Reply via email to