You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Mark Miller <ma...@gmail.com> on 2010/08/24 22:32:43 UTC
Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
(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(TestCachingWrapperFilter.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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
(from TestCachingWrapperFilter)
Posted by Michael McCandless <lu...@mikemccandless.com>.
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
<lu...@mikemccandless.com> 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
> <lu...@mikemccandless.com> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>>>
>>>
>>>> -----Original Message-----
>>>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>>> Sent: Tuesday, August 24, 2010 11:38 PM
>>>> To: dev@lucene.apache.org
>>>> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>>>> >
>>>> >
>>>> >> -----Original Message-----
>>>> >> From: Mark Miller [mailto:markrmiller@gmail.com]
>>>> >> Sent: Tuesday, August 24, 2010 10:33 PM
>>>> >> To: dev@lucene.apache.org
>>>> >> 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: dev-unsubscribe@lucene.apache.org For
>>>> >> additional commands, e-mail: dev-help@lucene.apache.org
>>>> >
>>>> >
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>>>> > additional commands, e-mail: dev-help@lucene.apache.org
>>>> >
>>>> >
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>>> commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
(from TestCachingWrapperFilter)
Posted by Michael McCandless <lu...@mikemccandless.com>.
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
<lu...@mikemccandless.com> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>>
>>
>>> -----Original Message-----
>>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>>> Sent: Tuesday, August 24, 2010 11:38 PM
>>> To: dev@lucene.apache.org
>>> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>>> >
>>> >
>>> >> -----Original Message-----
>>> >> From: Mark Miller [mailto:markrmiller@gmail.com]
>>> >> Sent: Tuesday, August 24, 2010 10:33 PM
>>> >> To: dev@lucene.apache.org
>>> >> 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: dev-unsubscribe@lucene.apache.org For
>>> >> additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>> >
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>>> > additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>> >
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>>> commands, e-mail: dev-help@lucene.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
(from TestCachingWrapperFilter)
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Michael McCandless [mailto:lucene@mikemccandless.com]
>> Sent: Tuesday, August 24, 2010 11:38 PM
>> To: dev@lucene.apache.org
>> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>> >
>> >
>> >> -----Original Message-----
>> >> From: Mark Miller [mailto:markrmiller@gmail.com]
>> >> Sent: Tuesday, August 24, 2010 10:33 PM
>> >> To: dev@lucene.apache.org
>> >> 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: dev-unsubscribe@lucene.apache.org For
>> >> additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
>> > additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions (from TestCachingWrapperFilter)
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Michael McCandless [mailto:lucene@mikemccandless.com]
> Sent: Tuesday, August 24, 2010 11:38 PM
> To: dev@lucene.apache.org
> 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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
> >
> >
> >> -----Original Message-----
> >> From: Mark Miller [mailto:markrmiller@gmail.com]
> >> Sent: Tuesday, August 24, 2010 10:33 PM
> >> To: dev@lucene.apache.org
> >> 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: dev-unsubscribe@lucene.apache.org For
> >> additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For
> > additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
(from TestCachingWrapperFilter)
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <uw...@thetaphi.de> 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: uwe@thetaphi.de
>
>
>> -----Original Message-----
>> From: Mark Miller [mailto:markrmiller@gmail.com]
>> Sent: Tuesday, August 24, 2010 10:33 PM
>> To: dev@lucene.apache.org
>> Subject: Lucene Test Failure:
>> org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
>> (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: dev-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Lucene Test Failure: org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions (from TestCachingWrapperFilter)
Posted by Uwe Schindler <uw...@thetaphi.de>.
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: uwe@thetaphi.de
> -----Original Message-----
> From: Mark Miller [mailto:markrmiller@gmail.com]
> Sent: Tuesday, August 24, 2010 10:33 PM
> To: dev@lucene.apache.org
> Subject: Lucene Test Failure:
> org.apache.lucene.search.TestCachingWrapperFilter.testEnforceDeletions
> (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: dev-unsubscribe@lucene.apache.org For additional
> commands, e-mail: dev-help@lucene.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org