[
https://issues.apache.org/jira/browse/LUCENE-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-2158:
---------------------------------------
Attachment: LUCENE-2158.patch
Attached patch.
Jake/John, hopefully this explains what you guys were seeing in stress testing
Lucene NRT!
> NRT can temporarily lose deletions at high indexing rates
> ---------------------------------------------------------
>
> Key: LUCENE-2158
> URL: https://issues.apache.org/jira/browse/LUCENE-2158
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 2.9.2, 3.0.1, 3.1
>
> Attachments: LUCENE-2158.patch
>
>
> OK, I found a sneaky case where NRT can temporarily lose deletions.
> The deletions aren't permanently lost - they are seen on the next
> opened NRT reader.
> It happens like this (in IW.getReader):
> * First flush() is called, to flush added docs & materialize the
> deletes.
> * The very next statement enters a sync'd block to open the reader,
> but, if indexing rate is very high, and threads get scheduled
> "appropriately", a "natural" flush (due to RAM buffer being full
> or flush doc count being reached) could be hit before the sync
> block is entered, in which case that 2nd flush won't materialize
> the deletes associated with it, and the returned NRT reader will
> only see its adds until it's next reopened.
> The fix is simple -- we should materialize deletes inside the sync
> block, not during the flush.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
