Thanks for also taking a look at the test failures! On 20 July 2012 19:14, Robert Muir <rcm...@gmail.com> wrote: > Hi Martinj: thanks for looking into this! > > I think have a better fix for these: > > the problem is actually in the AssertingAtomicReaders that > AssertingDirectoryReader wraps its subreaders with. > So I added the invisible-cache-key hack there, and removed it > completely from LuceneTestCase. Yes this was the problem. I think this fix wouldn't make hudson fail again. Since the FC insanity can't be detected.
During some test runs the AtomicReaderContext (in Collector#setNextReader method) contains a SlowCompositeReaderWrapper and this reader wraps another reader something like this: SlowCompositeReaderWrapper(ParallelCompositeReader(FCInvisibleMultiReader(StandardDirectoryReader(segments_4:9 _0(5.0):C463 _1(5.0):C930 _2(5.0):C378 _3(5.0):C184)))) This used to cause the FC insanity test failures, but is this a scenario that actually needs to be tested? Having a top level readercontext in the setNextReader method seems like wrong usage to me. Martijn --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
