Hi, Maybe TestNRQ does not like SimpleText (it seeks heavily), so maybe thats the reason (we should check that with the seed) and add assume. Do other MTQ tests allow SimpleText (like Fuzzy, which is also heavy)? With Clover the NRQ tests then gets *very* slow. Compare with TestNRQ32, which succeeded in a few seconds on the same run, just because of different random settings.
Because of the instrumentation level per statement, all tight loops take forever with clover. But changing to "method" level removes all the interesting information for us. We could also add a @NoClover annotation. We would need no sysprops for that, it would be enough to do a Class.forName on any of the clover classes to find out if clover is "active" for the current test run. Maybe we should raise the JVM setting for the code cache when running with clover, because clover-instrumented class files are a lot more "complex" for hotspot. ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of > Dawid Weiss > Sent: Thursday, April 19, 2012 9:38 AM > To: dev@lucene.apache.org > Subject: Re: [JENKINS] Lucene-trunk - Build # 1899 - Failure > > I'll try to inspect later today why these are so slow in that run: > > [junit4] <JUnit4> says g'day! Master seed: C26BAC36B9BF265D > > [junit4] Suite: org.apache.lucene.index.TestByteSlices > [junit4] Completed in 1852.84s, 1 test > > [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64 > [junit4] Completed in 4251.28s, 34 tests > > Dawid > > On Thu, Apr 19, 2012 at 9:28 AM, Dawid Weiss > <dawid.we...@cs.put.poznan.pl> wrote: > >> I have seen this on jenkins several times (especially with Clover > instrumentation). In this case instrumentation was running. > > > > Clover is a hog, we've experienced that too. > > > >> I think its caused by too many instrumentation (per statement) in heavy > >> tests > like TestNRQ or similar. Unfortunately we don’t see here, which test exactly > was leading to this output. > > > > I don't think you'd be able to see that precisely anyway because these > > are printed to two different stream buffers -- it bypasses Java's > > PrintStreams and dumps directly to the original file descriptor. > > > > Dawid > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
