Hi, We could emulate the same thing (the repeating beaster) with pure Ant:
Just repeat the "test" target, which can be done using ant-contrib's "for" task or (much simplier) a groovy script using antcall on the test target. Should we provide this "beaster" in common-build? "ant beast-tests -Dbeast.iter=100 -Dtestcase=..." Very easy to implement and makes it easier to use for the python haters - and comes embedded... 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: Friday, August 08, 2014 3:48 PM > To: Lucene/Solr dev > Subject: Re: Test iterations > > On Fri, Aug 8, 2014 at 9:35 AM, Uwe Schindler <u...@thetaphi.de> wrote: > > Hi Dawid, > > > > Thanks for the very good explanation! Indeed the main problem with > tests.iters is the static initializers. Maybe put that explanation into the > Wiki! I > sometimes also need to remember it, so it should be documented. > > > > One (only theoretical) way to solve the whole thing could be: > > Load the class(es) in a separate classloader for every repeated > > execution,... but of course this will very fast blow up your permgen > > (java 6, 7) or anything else we don't know about (java 8). In fact the > > separate classloader approach is not different from Mike's scripts, > > just that Mike's script creates a new classloader by forking a new > > JVM. In fact I don't think the separate classloader approach would be > > much faster, because the class clones will all have separate > > compilation paths in Hotspot, so Hotspot cannot share the same > > assembler code. So except the JVM startup time, you gain nothing. Just > > permgen issues :-) > > The big thing the python beasting scripts avoids is all the ant overhead to > just > get to the point where it actually spawns the JVM to run the test. Really, > that's all the beasting script does: directly spawn the JVM on the test runner > (after running "ant test-compile" up > front) and then parse its output/events. > > The distributed test runner, which uses rsync/ssh to run tests on N machines, > is very different from the beasting script: it runs all Lucene's tests > (instead of > a single test over and over) across N JVMs on M machines. It "cheats" by > taking the union of all CLASSPATHs ... > but this is a huge win because it means all testing is fully concurrent, not > just > concurrent within one module. This script can also repeat, which means once > all lucene tests finish, re-en-queue all of them again. > > Mike McCandless > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > 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
