[ https://issues.apache.org/jira/browse/LUCENE-3348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13073535#comment-13073535 ]
Michael McCandless commented on LUCENE-3348: -------------------------------------------- Thanks Simon; I'll make both of those fixes. Unfortunately there is still at least one more thread safety issue that I'm trying to track down... beasting uncovered a good seed. > IndexWriter applies wrong deletes during concurrent flush-all > ------------------------------------------------------------- > > Key: LUCENE-3348 > URL: https://issues.apache.org/jira/browse/LUCENE-3348 > Project: Lucene - Java > Issue Type: Bug > Components: core/index > Reporter: Michael McCandless > Assignee: Michael McCandless > Fix For: 3.4, 4.0 > > Attachments: LUCENE-3348.patch, LUCENE-3348.patch > > > Yonik uncovered this with the TestRealTimeGet test: if a flush-all is > underway, it is possible for an incoming update to pick a DWPT that is > stale, ie, not yet pulled/marked for flushing, yet the DW has cutover > to a new deletes queue. If this happens, and the deleted term was > also updated in one of the non-stale DWPTs, then the wrong document is > deleted and the test fails by detecting the wrong value. > There's a 2nd failure mode that I haven't figured out yet, whereby 2 > docs are returned when searching by id (there should only ever be 1 > doc since the test uses updateDocument which is atomic wrt > commit/reopen). > Yonik verified the test passes pre-DWPT, so my guess is (but I > have yet to verify) this test also passes on 3.x. I'll backport > the test to 3.x to be sure. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org