[
https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651762#comment-13651762
]
Shai Erera commented on LUCENE-4975:
------------------------------------
Ok some more insights ... I think this additional chain of events occurs:
* IW's ctor reads gen 9, and SegmentInfos.getSegmentsFileName returns
segments_9.
* IFD then successfully reads both segments_9 and segments_a, ending up w/ two
commit points.
* IFD sorts them and passes to IndexDeletionPolicy (KeepLastCommit) which
deletes segments_9 and keeps segments_a
* IFD marks that startingCommitDeleted, as it is
And here's what I still don't understand -- for some reason, IW creates a new
commit point, segments_a, with the commitData from segments_9. Still need to
dig into that.
In the meanwhile, I made the above change to the hanlder (to rollback(), not
close()), and 430 iterations passed. Not sure if that's the right way to go ...
if IW.close() didn't commit ... ;)
> Add Replication module to Lucene
> --------------------------------
>
> Key: LUCENE-4975
> URL: https://issues.apache.org/jira/browse/LUCENE-4975
> Project: Lucene - Core
> Issue Type: New Feature
> Reporter: Shai Erera
> Assignee: Shai Erera
> Attachments: LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch,
> LUCENE-4975.patch, LUCENE-4975.patch, LUCENE-4975.patch
>
>
> I wrote a replication module which I think will be useful to Lucene users who
> want to replicate their indexes for e.g high-availability, taking hot backups
> etc.
> I will upload a patch soon where I'll describe in general how it works.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
