OK I just cut this test over to SMS, and, took steps to make sure the reader is not GC'd. It seems to be passing now ;)
Mike On Tue, Aug 24, 2010 at 6:46 PM, Michael McCandless <[email protected]> wrote: > Hmm so cms.sync() wasn't it -- I just saw it fail again. > > Uwe you are right -- we are failing to keep a hard ref to the old > reader, for this one assert. > > Yet if I try to keep a ref, I still see it sometimes fail... still digging... > > Mike > > On Tue, Aug 24, 2010 at 5:49 PM, Michael McCandless > <[email protected]> wrote: >> Yeah the key should still have a hard ref. >> >> The key is either the SegmentReader instance, or it's CoreReader >> instance. The tests holds a hard ref to the parent reader, which then >> references the subs. >> >> I think it may instead be due to CMS, ie, we reopen the reader before >> a merge completes, then the merge completes, then the next reopen >> (which assumes there will be no changes) sees the completed merge as a >> change. >> >> I'll try inserting CMS.sync() to the test... >> >> Mike >> >> On Tue, Aug 24, 2010 at 5:44 PM, Uwe Schindler <[email protected]> wrote: >>> Right, but has the key any refs? >>> >>> This was my only explanation for the bug. My problem is, that I had no time >>> to look closely into the test and I did not understand the new deletion >>> modes completely and what the test tries to do. This changed since 3.0 when >>> I modified the filter the last time (at ApacheCon US). >>> >>> ----- >>> Uwe Schindler >>> H.-H.-Meier-Allee 63, D-28213 Bremen >>> http://www.thetaphi.de >>> eMail: [email protected] >>> >>> >>>> -----Original Message----- >>>> From: Michael McCandless [mailto:[email protected]] >>>> Sent: Tuesday, August 24, 2010 11:38 PM >>>> To: [email protected] >>>> Subject: Re: Lucene Test Failure: >>>> org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions >>>> (from TestCachingWrapperFilter) >>>> >>>> Wait -- it's a WeakHashMap right? Entries should not be removed unless >>> the >>>> key no longer has any hard refs? >>>> >>>> Mike >>>> >>>> On Tue, Aug 24, 2010 at 5:34 PM, Uwe Schindler <[email protected]> wrote: >>>> > Weh ad the same on hudson a few days ago. The problem is a too heavy >>>> > GC (because if GC is very active it removes the entry from the cache >>>> > and then this error occurs). >>>> > >>>> > This is a bug in the test. To test this correctly we can either: >>>> > - during test replace WeakHashMap by a conventional HashMap (the map >>>> > is package private, maybe we replace it in the test) >>>> > - hold a reference to the cache entry during the test (that is the >>>> > DocIdSet) >>>> > >>>> > Uwe >>>> > >>>> > ----- >>>> > Uwe Schindler >>>> > H.-H.-Meier-Allee 63, D-28213 Bremen >>>> > http://www.thetaphi.de >>>> > eMail: [email protected] >>>> > >>>> > >>>> >> -----Original Message----- >>>> >> From: Mark Miller [mailto:[email protected]] >>>> >> Sent: Tuesday, August 24, 2010 10:33 PM >>>> >> To: [email protected] >>>> >> Subject: Lucene Test Failure: >>>> >> org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletion >>>> >> s >>>> >> (from TestCachingWrapperFilter) >>>> >> >>>> >> Error Message >>>> >> >>>> >> expected:<2> but was:<3> >>>> >> Stacktrace >>>> >> >>>> >> junit.framework.AssertionFailedError: expected:<2> but was:<3> >>>> >> at >>>> >> >>>> > org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions >>>> > (Test >>>> >> CachingWrapperFilter.java:228) >>>> >> at >>>> >> org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:380 >>>> >> ) >>>> >> at >>>> >> org.apache.lucene.util.LuceneTestCase.run(LuceneTestCase.java:372) >>>> >> Standard Output >>>> >> >>>> >> NOTE: random codec of testcase 'testEnforceDeletions' was: PreFlex >>>> >> NOTE: random locale of testcase 'testEnforceDeletions' was: zh_CN >>>> >> NOTE: random timezone of testcase 'testEnforceDeletions' was: >>>> >> Etc/GMT+4 >>>> >> NOTE: random seed of testcase 'testEnforceDeletions' was: - >>>> >> 46038615367376670 >>>> >> >>>> >> --------------------------------------------------------------------- >>>> >> To unsubscribe, e-mail: [email protected] For >>>> >> additional commands, e-mail: [email protected] >>>> > >>>> > >>>> > >>>> > --------------------------------------------------------------------- >>>> > To unsubscribe, e-mail: [email protected] For >>>> > additional commands, e-mail: [email protected] >>>> > >>>> > >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] For additional >>>> commands, e-mail: [email protected] >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
