> Yeah, I had a shell script looping "ant test" because of past issues > with tests.iters, but I haven't tried it lately...
I think I commented on one of the issues related to OOMs -- you don't read my messages :) The recent update to the runner brings two of the features we once spoke about: 1) if you limit the run to a single JVM (which is effectively done by -Dtestcase=...) then the output will be pumped to the console incrementally (not dumped at the end of the test). 2) I spill the output to disk; tested on hundreds of megabytes of sysouts, doesn't OOM. > And if there *is* an issue with a thread from one run messing up > another run, best to just do separate "ant test" invocations for now I It depends -- if the leaked threads react to interrupt() and terminate then the following tests will run normally. If the leaked threads don't terminate (which is the case with all thread pool workers, for example) then these are promoted to "zombie" threads and whatever tests follow are assumption-ignored. The reason for this is that we cannot be sure what those unterminated threads are doing in the background. This also can be turned off, see the annotations/ options on LuceneTestCase if you care. A shell loop will do too of course. D. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
