river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tom White" <tom.e.wh...@gmail.com>
Subject Re: Concurrency and River
Date Thu, 04 Oct 2007 08:34:45 GMT
I had some success distributing JUnit tests using JavaSpaces as a part
of my ComputeFarm project (https://computefarm.dev.java.net/). It's
been a couple of years, but I think the ideas and code may still be
relevant. See https://computefarm.dev.java.net/samples.html for a
short description.



On 04/10/2007, Bill Venners <bv-svp@artima.com> wrote:
> 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
> > HTTP
> > 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?
> Bill

View raw message