> I'll take a look at that. The only thing new to surefire in this patch > is really dynamic allocation of tests to forked processes, since all > the other stuff you mention is already supported.
Well, it's a lot more than just that ;) But I agree most of this stuff (randomization, thread leak detection etc.) is beyond Surefire's scope which is well defined. > Right; there is little chance of actually tracking what went wrong > in the current logging regime; it would need to be beefed up > with which vm and when things happened. It's really tricky. I'm not even saying we got to the point where it's good but there's been a good few attempts... If you peek here: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3366/consoleText it's one of the possible reports, it just lists suites that executed and VMs they executed on, as in: [junit4:junit4] Suite: org.apache.solr.cloud.OverseerTest [junit4:junit4] Completed on J1 in 36.72s, 8 tests If a suite ends with a failure it'll have an indented output (interleaved stdout 1> and stderr 2>), as in: [junit4:junit4] Suite: org.apache.solr.TestSolrCoreProperties [junit4:junit4] 2> 3615 T571 oejs.Server.doStart jetty-8.1.2.v20120308 [junit4:junit4] 2> 3855 T571 oejs.AbstractConnector.doStart Started [email protected]:29098 ... here it's not even a particular test that caused the failure but an afterclass hook. [junit4:junit4] ERROR 0.00s J1 | TestSolrCoreProperties (suite) <<< [junit4:junit4] > Throwable #1: com.carrotsearch.randomizedtesting.ThreadLeakError: 4 threads leaked from SUITE scope at org.apache.solr.TestSolrCoreProperties: The number of places where things can start logging or where they can go bonkers are absolutely astonishing -- the static initializers, etc. you mentioned but also hanging shutdown hooks, finalizers or threads stuck in native code (preventing jvm exit). > This is basically unchanged in his patch; we capture all process output. Ok. > Yuck. Andreas's patch sets distinct environment variable within each forked > vm, > which is about as far as I think it's /nice/ to go. Separate cwd > sounds very un-maven like; > I wouldn't really expect maven users to have this problem ;) It's about tests not being a maven or ant or whatever else. I can bet a lot of people will have conflicts like the ones I mentioned, it's just life -- a lot of badly written tests just happen. I recalled another reason we split cwds -- once you get a JVM crash it's easier to tell which one it was (and J9 produces several several files in the CWD, for example). > We're not adding support for starting vmware images ;) Everything in the right time ;) D. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
