OK I committed fixes for the monster tests. They were all trying to add Integer.MAX_VALUE docs, but should use IndexWriter.MAX_DOCS instead.
I verified the change at least compiles, but didn't run all the monster tests... Mike McCandless http://blog.mikemccandless.com On Sat, Oct 4, 2014 at 4:56 AM, Michael McCandless <[email protected]> wrote: > Hi Shawn, > > Thank you for running these! We really ought to have a Jenkins job > somewhere that does these weekly... > > I committed a fix for the Test2BTerms failure, just the annotation > that exempts it from the "too must stuff printed to stdout" rule. > > The other failure is interesting: that "too many docs indexed" check > is a recent check we added to IW (LUCENE-5843)... it's spooky that > these tests are in fact doing so. We need to fix them not to! I'll > dig ... > > Mike McCandless > > http://blog.mikemccandless.com > > > On Sat, Oct 4, 2014 at 1:56 AM, Shawn Heisey <[email protected]> wrote: >> I've been running an inclusive set of tests on branch_5x to do what I >> can for the release effort. It kept failing with OOME, so I kept >> increasing the heap size. After trying 2GB and 3GB, I finally bumped it >> all the way to 8GB and dropped the JVM count to 1, but that resulted in >> different problems. Here's the commandline that I used, followed by the >> list of failures: >> >> ant -Dtests.jvms=1 -Dtests.heapsize=8g -Dtests.nightly=true >> -Dtests.weekly=true -Dtests.monster=true clean test | tee ~/b5x-testlog.txt >> >> [junit4] Tests with failures: >> [junit4] - org.apache.lucene.index.Test2BTerms (suite) >> [junit4] - org.apache.lucene.index.Test2BNumericDocValues.testNumerics >> [junit4] - org.apache.lucene.index.Test2BNumericDocValues (suite) >> [junit4] - >> org.apache.lucene.index.Test2BSortedDocValues.testFixedSorted >> [junit4] - org.apache.lucene.index.Test2BSortedDocValues.test2BOrds >> [junit4] - org.apache.lucene.index.Test2BSortedDocValues (suite) >> [junit4] >> [junit4] >> [junit4] JVM J0: 0.90 .. 76575.00 = 76574.10s >> [junit4] Execution time total: 21 hours 16 minutes 15 seconds >> >> All of them except for Test2BTerms failed because of this problem: >> >> [junit4] > Throwable #1: java.lang.IllegalStateException: number >> of documents in the index cannot exceed 2147483519 >> >> Test2BTerms failed for an entirely different reason: >> >> [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=Test2BTerms >> -Dtests.seed=9F2773FB226B1E02 -Dtests.nightly=true -Dtests.weekly=true >> -Dtests.slow=true -Dtests.locale=es_PE >> -Dtests.timezone=America/Los_Angeles -Dtests.file.encoding=UTF-8 >> [junit4] ERROR 0.00s | Test2BTerms (suite) <<< >> [junit4] > Throwable #1: java.lang.AssertionError: The test or >> suite printed 3012118 bytes to stdout and stderr, even though the limit >> was set to 8192 bytes. Increase the limit with @Limit, ignore it >> completely with @SuppressSysoutChecks or run with -Dtests.verbose=true >> [junit4] > at >> __randomizedtesting.SeedInfo.seed([9F2773FB226B1E02]:0) >> [junit4] > at java.lang.Thread.run(Thread.java:745) >> >> I'm clueless about how to fix the number of documents going too high. I >> could probably fix the other one, if someone can tell me what the >> preferred fix is. >> >> I haven't tried this on the 4_10 branch, because it takes so long to >> run. I've started a similar commandline in branch_5x/solr to see what >> happens. >> >> Thanks, >> Shawn >> >> >> --------------------------------------------------------------------- >> 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]
