[
https://issues.apache.org/jira/browse/LUCENE-3028?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020224#comment-13020224
]
Simon Willnauer commented on LUCENE-3028:
-----------------------------------------
bq. hasn't failed since above fix
thanks for reporting back, the failure you reported was due to a reset call at
the wrong position. I was allowing blocked flushed to continue before I reset
the the var that ensures that the blocked flushes continue before a full flush
finished.
> IW.getReader() returns inconsistent reader on RT Branch
> -------------------------------------------------------
>
> Key: LUCENE-3028
> URL: https://issues.apache.org/jira/browse/LUCENE-3028
> Project: Lucene - Java
> Issue Type: Bug
> Components: Index
> Affects Versions: Realtime Branch
> Reporter: Simon Willnauer
> Assignee: Simon Willnauer
> Fix For: Realtime Branch
>
> Attachments: LUCENE-3028.patch, LUCENE-3028.patch, realtime-1.txt
>
>
> I extended the testcase TestRollingUpdates#testUpdateSameDoc to pull a NRT
> reader after each update and asserted that is always sees only one document.
> Yet, this fails with current branch since there is a problem in how we flush
> in the getReader() case. What happens here is that we flush all threads and
> then release the lock (letting other flushes which came in after we entered
> the flushAllThread context, continue) so that we could concurrently get a new
> segment that transports global deletes without the corresponding add. They
> sneak in while we continue to open the NRT reader which in turn sees
> inconsistent results.
> I will upload a patch soon
--
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
