[
https://issues.apache.org/jira/browse/LUCENE-4975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13651847#comment-13651847
]
Robert Muir commented on LUCENE-4975:
-------------------------------------
{quote}
I chatted about this with Mike and he confirmed my reasoning. This is very slim
chance, and usually indicates a truly bad (or crazy) IO subsystem (i.e. not
like MDW throwing random IOEs on opening the same file over and over again). I
think perhaps this can be solved in IW by having it refer to the latest commit
point read by IFD and not what it read. This seems safe to me, but perhaps an
overkill. Anyway, it belongs in a different issue.
What also happened here is that IW overwrote segments_a (violating write-once
policy), which MDW didn't catch because for replicator tests I need to turn off
preventDoubleWrite. Mike also says that IW doesn't guarantee write-once if it
hits exceptions ...
{quote}
Sorry, i disagree and am against this.
The bug is that IndexWriter.close() waits for merges and commits. Lets quit
kidding ourselves ok?
> 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]
