Hi, > 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(FCInvisibleMultiRead > er(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.
That is wanted! We want to test SlowMultiReaderWrapper and verify that it really behaves like a full conformant AtomicReader. Because of that we sometimes war with it. The fix Robert did is fine and is identical to the one we did in the past. As this is no real Lucene usage pattern, not detecting the obvious cache violation is wanted here. For incorrect Lucene usage (like getting a field cache entry on a slow wrapper), we can still warn the user. Buf for tests this insanity is wanted by the wrapping. Uwe --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
