river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Venners <bv-...@artima.com>
Subject Re: Concurrency and River
Date Thu, 04 Oct 2007 00:14:41 GMT
Hi Mark,

On Oct 3, 2007, at 2:16 PM, Mark Brouwer wrote:

>> To speed up unit testing, my idea has been that I keep a  
>> SuiteRunner server VM running at all time while developing, and  
>> when I run tests what I actually do is feed jobs to that server.  
>> This way I could avoid starting up a new JVM each time I want to  
>> run a test. So what seems to make sense is to embed a JavaSpace  
>> inside that SuiteRunner server.
> Assuming you keep the SuiteRunner JVM running and submit suites  
> through
> a JavaSpace you will likely run into what I think a lot of people also
> consider the hard parts of working with Jini/RMI (and often  
> overlooked)
> namely that you must make sure that you will be able to provide as a
> codebase annotation all classes your test suites will depend on.
> Assuming people are able to do that you will likely run into the fact
> the JVM that is about to (re)execute the testsuites has those JAR  
> files
> cached (you can also prevent from using JAR files though).
Wouldn't the JVM not cache JARs if the HTTP response header says  
cache-control: no cache?

> There are ways to solve some of these problems by making sure you  
> end up
> with a different codebase annotation each time or configuring e.g. a
> smart jar: protocol handler (you can find one in the Seven source  
> code)
> for your JVM that doesn't caches JAR files but is able to verify
> whether a newer JAR file is available and will use the newer JAR files
> for new class loaders created.
I suppose there could also be a local mode in which classes are  
loaded off the local disk through a new URLClassLoader created each  
run. This is what SuiteRunner does now. This is probably what most  
developers would want to do at their workstations.

> I do wonder whether in general people have unit tests that really take
> a long time to run, I have only a few that take a long time to  
> complete
> and these are for testing concurrency utilities such a thread pools,
> blocking queues, etc. Parallelism helps a lot here because the tests
> themselves are not consuming any significant CPU most of the time, but
> there is no need to distribute these, local parallelization is good  
> enough.
Well, I know there are companies who make money selling solutions  
that make builds run faster. This would be a tool that makes tests  
run faster. As cores multiply, it makes sense to me to exploit them  
to make tests run faster on developer's boxes. Need not be  
distributed to other boxes. Although on a continuous integration  
server, distribution might make sense. On a developer's box, you  
don't need to run every test every time, but on the continuous  
integration server you do, repeatedly. If you can speed up the cycles  
by adding a few old computers to the grid, I think people would see  
that as a good thing.

> BTW I'm still using your modified SuiteRunner code to make it use
> PreferredClassProvider/PreferredClassLoader, control the codebase
> annotation for serving JAR files of mobile code from an integrated  
> server and have written a Ant task for it, as well as a JUnit XML
> reporter so you can use the Ant junitreport. I needed those changes to
> have it act as a proper Jini client that was able to serve mobile code
> to the services I test through SuiteRunner. Everything is available
> through the Cheiron project under the ALv2, if you have any questions
> you know where to find me for I think I've solved some of the problems
> you might run into.
I'd forgotten about that. Hmm. Since you kind of made a little fork,  
would it be alright with you if I didn't make new releases of the  
Java SuiteRunner going forward?


View raw message