[
https://issues.apache.org/jira/browse/LUCENE-2769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-2769:
----------------------------------
Attachment: LUCENE-2769_SegmentMerger.patch
Here a new SegmentMerger now working only on atomic readers. All "normal" tests
pass, but it seems that addIndexesWithThreads fails during merging term
vectors. This is not clear, all other tests pass and the created indexes are
fine.
Mike: Do you understand that? The problem seems to be some thread safety issue
in addIndexes(IndexReader...). Not sure who changes who's internal structures?
Maybe suddenly subreaders change?
> FilterIndexReader in trunk does not implement getSequentialSubReaders()
> correctly
> ---------------------------------------------------------------------------------
>
> Key: LUCENE-2769
> URL: https://issues.apache.org/jira/browse/LUCENE-2769
> Project: Lucene - Java
> Issue Type: Bug
> Affects Versions: 4.0
> Reporter: Uwe Schindler
> Attachments: LUCENE-2769.patch, LUCENE-2769.patch,
> LUCENE-2769_norms.patch, LUCENE-2769_norms.patch, LUCENE-2769_norms.patch,
> LUCENE-2769_SegmentMerger.patch, LUCENE-2769_SegmentMerger.patch
>
>
> Since LUCENE-2459, getSequentialSubReaders() in FilterIndexReader returns
> null, so it returns an atomic reader. But If you call then any of the enum
> methods, it throws Exception because the underlying reader is not atomic.
> We should move the null-returning method to SlowMultiReaderWrapper and fix
> FilterIndexReader's default to return in.getSequentialSubReaders(). Ideally
> an implementation must of course also wrap the sub-readers.
> If we change this we have to look into other Impls like the
> MultiPassIndexSplitter if we need to add atomicity.
--
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]
