[
https://issues.apache.org/jira/browse/LUCENE-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12968418#action_12968418
]
Simon Willnauer commented on LUCENE-2802:
-----------------------------------------
I changed DirectoryReader to use the cloned version of SegmentInfos instead of
two of them inconsistently. The only failure I get is on TestIndexWriterReader
line 105
{code}
r1.close();
writer.close();
assertTrue(r2.isCurrent());
{code}
where the writer is closed and afterwards it checks if the r2 reader still is
the current one which failes since the writer.close() method changes the
version of the SegmentInfos. In my opinion this is actually the semantics I
would expect from #isCurrent(), the question is if we would want to change the
semantics to return false from #isCurrent if the writer we used to obtain the
reader from is closed.
I think we should consider it for consistency and simplicity though.
> DirectoryReader ignores NRT SegmentInfos in #isOptimized()
> ----------------------------------------------------------
>
> Key: LUCENE-2802
> URL: https://issues.apache.org/jira/browse/LUCENE-2802
> Project: Lucene - Java
> Issue Type: Bug
> Components: Search
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Attachments: LUCENE-2802.patch
>
>
> DirectoryReader only takes shared (with IW) SegmentInfos into account in
> DirectoryReader#isOptimized(). This can return true even if the actual
> realtime reader sees more than one segments.
> {code}
> public boolean isOptimized() {
> ensureOpen();
> // if segmentsInfos changes in IW this can return false positive
> return segmentInfos.size() == 1 && !hasDeletions();
> }
> {code}
> DirectoryReader should check if this reader has a non-nul segmentInfosStart
> and use that instead
--
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]
