[ https://issues.apache.org/jira/browse/LUCENE-2158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-2158. ---------------------------------------- Resolution: Fixed > 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: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org