> If you have tests like that you end up having to use a new process for each
> test class. That's like having to decide between forkMode once and always
> in the single-threaded configuration. But yes, I've seen such tests as well
> :).
I agree that running a suite-per-jvm is the ultimate isolation but it
just adds so much overhead... But you're right -- it's a possibility,
sure.
> Gladly, I didn't have to do anything there - it pretty much was there
> already. The current code uses pipes (stdin/stdout/stderr) to communicate
> between the processes, with some specific escaping and op-code mechanism
> that allows to sort out test results and events, and stuff written to
> stdout / stderr within the tests.
This just doesn't work around the corner cases of a child vm crashing.
Believe me or not, this is pretty frequent in Lucene/Solr tests as
folks run with bleeding edge releases and on exotic platforms. What
happens is different VMs report crashes to different output
descriptors (stderr, stdout), this bypasses any Java code and can
basically happen at any time so it's kind of difficult for parsing on
the receiver side... I initially had it done this way because it's a
natural pipe but it didn't work on more than one occasion, hence the
decision to switch to another file for propagating events back to the
master/ controller node. Another upside is that this event file is
fully asynchronous (unlike the pipe which is blocking once it reaches
a system limit) and the VM just flushes all the events without ever
waiting for the master to even read them. This matters for folks with
beefy hardware (24 cores running, etc.) when the master had trouble
keeping up flushing I/O buffers and was effectively becoming the
bottleneck.
> I know exactly what you mean - I have to deal with tests that require
> database access (they set up test data, do some JPA, and perform a
> rollback). For such scenarios, I have added a feature that replaces the
> string ${surefire.threadNumber} in the system properties and in the argLine
> with the number of the executing thread, ranging [1..threadCount]. For me,
My idealistic idea was to have tests running in parallel out of the
box. In cases like yours it's obviously not going to happen. I like
the system property idea.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
