here is what i was worried about, if we cannot fix, i can revert back to
forking. This is not reproduceable all the time:
[junit] Testcase:
testParallelMultiSort(org.apache.lucene.search.TestSort): Caused an ERROR
[junit] java.util.ConcurrentModificationException
[junit] java.lang.RuntimeException:
java.util.ConcurrentModificationException
[junit] at
org.apache.lucene.search.ParallelMultiSearcher.foreach(ParallelMultiSearcher.java:216)
[junit] at
org.apache.lucene.search.ParallelMultiSearcher.search(ParallelMultiSearcher.java:121)
[junit] at
org.apache.lucene.search.Searcher.search(Searcher.java:49)
[junit] at
org.apache.lucene.search.TestSort.assertMatches(TestSort.java:965)
[junit] at
org.apache.lucene.search.TestSort.runMultiSorts(TestSort.java:891)
[junit] at
org.apache.lucene.search.TestSort.testParallelMultiSort(TestSort.java:629)
[junit] at
org.apache.lucene.util.LuceneTestCase.runBare(LuceneTestCase.java:208)
[junit] Caused by: java.util.ConcurrentModificationException
[junit] at
java.util.WeakHashMap$HashIterator.nextEntry(WeakHashMap.java:762)
[junit] at
java.util.WeakHashMap$KeyIterator.next(WeakHashMap.java:795)
[junit] at
org.apache.lucene.search.FieldCacheImpl.getCacheEntries(FieldCacheImpl.java:75)
[junit] at
org.apache.lucene.util.FieldCacheSanityChecker.checkSanity(FieldCacheSanityChecker.java:72)
[junit] at
org.apache.lucene.search.FieldCacheImpl$Cache.printNewInsanity(FieldCacheImpl.java:205)
[junit] at
org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:194)
[junit] at
org.apache.lucene.search.FieldCacheImpl.getInts(FieldCacheImpl.java:357)
[junit] at
org.apache.lucene.search.FieldCacheImpl$IntCache.createValue(FieldCacheImpl.java:373)
[junit] at
org.apache.lucene.search.FieldCacheImpl$Cache.get(FieldCacheImpl.java:183)
[junit] at
org.apache.lucene.search.FieldCacheImpl.getInts(FieldCacheImpl.java:357)
[junit] at
org.apache.lucene.search.FieldComparator$IntComparator.setNextReader(FieldComparator.java:438)
[junit] at
org.apache.lucene.search.TopFieldCollector$OneComparatorNonScoringCollector.setNextReader(TopFieldCollector.java:95)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:207)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:197)
[junit] at
org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:175)
[junit] at
org.apache.lucene.search.MultiSearcher$MultiSearcherCallableWithSort.call(MultiSearcher.java:420)
[junit] at
org.apache.lucene.search.MultiSearcher$MultiSearcherCallableWithSort.call(MultiSearcher.java:394)
[junit] at
java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
[junit] at java.util.concurrent.FutureTask.run(FutureTask.java:138)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
[junit] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[junit] at java.lang.Thread.run(Thread.java:619)
[junit]
[junit]
[junit] TEST org.apache.lucene.search.TestSort FAILED
On Sun, Feb 21, 2010 at 2:10 AM, Robert Muir <rcm...@gmail.com> wrote:
> ok, can do. if it turns out there is a problem, we can revert until some
> work has been done on the tests.
>
>
> On Sat, Feb 20, 2010 at 5:45 PM, Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> Currently the tests run 1 jvm per test suite (eg, TestIndexWriter has
>> its own jvm), I believe, and we haven't seen test failures... so I
>> think for the most part tests are not interfering with each other
>> (messing up global state).
>>
>> It should be less likely that we see interactions across test suites
>> (but obviously still possible).
>>
>> I think we should commit this and then if there are somehow problems
>> we can address them, then?
>>
>> Mike
>>
>> On Sun, Feb 14, 2010 at 6:27 AM, Robert Muir <rcm...@gmail.com> wrote:
>> > its not just statics, I think we should really look at ensuring files
>> are
>> > closed etc, or eventually there will be a problem!
>> >
>> > I guess in general the tradeoff is, it requires us to have better test
>> code.
>> >
>> > On Sun, Feb 14, 2010 at 5:53 AM, Uwe Schindler <u...@thetaphi.de> wrote:
>> >>
>> >> At least we should check all core tests to not set any static defaults
>> >> without try...finally! Are there any possibilities inside
>> Eclipse/other-IDEs
>> >> to check this?
>> >>
>> >> Uwe
>> >>
>> >> -----
>> >> Uwe Schindler
>> >> H.-H.-Meier-Allee 63, D-28213 Bremen
>> >> http://www.thetaphi.de
>> >> eMail: u...@thetaphi.de
>> >>
>> >> > -----Original Message-----
>> >> > From: Michael McCandless [mailto:luc...@mikemccandless.com]
>> >> > Sent: Sunday, February 14, 2010 11:43 AM
>> >> > To: java-dev@lucene.apache.org
>> >> > Subject: Re: (LUCENE-1844) Speed up junit tests
>> >> >
>> >> > Wow -- this is MUCH faster! I think we should switch...
>> >> >
>> >> > It seems like we use a batchtest for all core tests, then for all
>> >> > back-compat tests, then once per contrib package? Ie, so "ant
>> >> > test-core" uses one jvm?
>> >> >
>> >> > I think we should simply fix any badly behaved tests (that don't
>> >> > restore statics). It's impressive we already have no test failures
>> >> > when we do this... I guess our tests are already cleaning things up
>> >> > (though also probably not often changing global state, or, changing
>> it
>> >> > in a way that'd lead other tests to fail).
>> >> >
>> >> > Mike
>> >> >
>> >> > On Sat, Feb 13, 2010 at 5:23 PM, Robert Muir <rcm...@gmail.com>
>> wrote:
>> >> > > On Fri, Nov 27, 2009 at 1:27 PM, Michael McCandless
>> >> > > <luc...@mikemccandless.com> wrote:
>> >> > >>
>> >> > >> Also one thing I'd love to try is NOT forking the JVM for each
>> test
>> >> > >> (fork="no" in the junit task). I wonder how much time that'd
>> buy...
>> >> > >>
>> >> > >
>> >> > > it shaves off a good deal of time on my machine.
>> >> > >
>> >> > > 'ant test-core': 4 minutes, 39 seconds -> 3 minutes, 3 seconds
>> >> > > 'ant test': 11 minutes, 8 seconds -> 7 minutes, 13 seconds
>> >> > >
>> >> > > however, it makes me a little nervous because i'm not sure all the
>> >> > tests
>> >> > > cleanup nicely if they change statics and stuff.
>> >> > > anyway, here's the trivial patch (you don't want fork=no, because
>> it
>> >> > turns
>> >> > > off assertions)
>> >> > >
>> >> > > Index: common-build.xml
>> >> > > ===================================================================
>> >> > > --- common-build.xml (revision 909395)
>> >> > > +++ common-build.xml (working copy)
>> >> > > @@ -398,7 +398,7 @@
>> >> > > </condition>
>> >> > > <mkdir dir="@{junit.output.dir}"/>
>> >> > > <junit printsummary="off" haltonfailure="no"
>> >> > maxmemory="512M"
>> >> > > - errorProperty="tests.failed"
>> >> > failureProperty="tests.failed">
>> >> > > + errorProperty="tests.failed"
>> >> > failureProperty="tests.failed"
>> >> > > forkmode="perBatch">
>> >> > > <classpath refid="@{junit.classpath}"/>
>> >> > > <assertions>
>> >> > > <enable package="org.apache.lucene"/>
>> >> > >
>> >> > > --
>> >> > > Robert Muir
>> >> > > rcm...@gmail.com
>> >> > >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> >> > For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> >>
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> >
>> > --
>> > Robert Muir
>> > rcm...@gmail.com
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: java-dev-h...@lucene.apache.org
>>
>>
>
>
> --
> Robert Muir
> rcm...@gmail.com
>
--
Robert Muir
rcm...@gmail.com
