db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: squeezing some multi-processing out of the nightly test runs?
Date Mon, 19 May 2008 11:14:10 GMT
Kristian Waagan <Kristian.Waagan@Sun.COM> writes:

> Knut Anders Hatlen wrote:
>> Rick Hillegas <Richard.Hillegas@Sun.COM> writes:
>>
>>> Mike Matrigali wrote:
>>>> I would like to get the nightly tests to run faster on machines that
>>>> have more than one cpu - or even hyperthreaded on a single cpu.
>>>> Since most of the tests are single threaded I think this means
>>>> somehow running more than one test at a time.  For me
>>>> it might even help if I was just able to run tests on 2 different
>>>> codelines on the same machine at the same time.
>>>> I think going forward this will be more and
>>>> more common for developers.  You can find reasonably priced laptops
>>>> nowadays that come dual core already.
>>>>
>>>> I know what outstanding issue is that the network tests default to the
>>>> same port.  I believe at least for the junit tests one can set a
>>>> different port number.  Does anyone know if this fixes all the
>>>> issues
>>>> for the junit tests - I think I have seen some tests try different ports
>>>> rather than the default one.
>>> Hi Mike,
>>>
>>> I don't know how much work is needed to make the junit tests
>>> independent of the port number. I can't find a JIRA which lists all of
>>> the problem cases. However, the following JIRAs may be helpful:
>>> DERBY-2440 and DERBY-2404.
>>
>> It is possible to change the port for all tests in a JUnit suite if we
>> run the suite like this:
>>
>>   java -Dport=XXX -DjmxPort=YYY ...
>
> Hi Knut Anders,
>
> Have you tested this?
> The last time I looked at it, the relevant code was only invoked for
> test runs in the DERBY_HARNESS_CONFIG configuration, which I believe
> is some kind of backward compatibility mode with respect to the old
> harness.
> It seems this mode can be triggered by various things, for instance if
> derby.system.home is specified, so people might see different behavior
> depending on how they start the tests.
>
> I also see that that some methods are using the constant DEFAULT_PORT
> directly, which suggests we are not quite there yet...

Yes, I tested it, but only after I sent the mail. :)

I saw the same behaviour as you describe. Both -Dport=XXX and
-DjmxPort=YYY only work if the JUnit test are run from the old harness.

It also looks like the replication tests have port 1527 hard-coded.

> I find this code, or at least the naming and the comments, a tad
> confusing. I would like to remove the notion of the old harness, and
> can do another pass and see if we can remove it now.

I don't think we have any JUnit tests in the old harness any more
(except the compatibility test, but that one doesn't use
TestConfiguration), so removing the notion of the old harness sounds
like a good idea to me.

-- 
Knut Anders

Mime
View raw message