db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tiago Espinha <tiago.de...@yahoo.co.uk>
Subject Re: regression test regressed
Date Wed, 14 Jul 2010 09:51:53 GMT
Oh I see, what you need is access to the port so that you can do your own 
calculations. I think that's fine really. I'd go with the static method for 
encapsulation reasons (even if the attribute is set as 'final').

Tiago


----- Original Message ----
From: Kristian Waagan <kristian.waagan@oracle.com>
To: derby-dev@db.apache.org
Sent: Wed, 14 July, 2010 10:42:18
Subject: Re: regression test regressed

On 14.07.10 11:28, Tiago Espinha wrote:
> Would you define MAX_PORTS_USED through a system property? I suppose we could
> keep a default limit that is a tight fit on the suites.All and if a property,
> say derby.tests.maxPortsUsed, is defined then we override it with that value.
>    

No, MAX_PORTS_USED would be defined in TestConfiguration as today.
My point was that parallel runners should be able to calculate port ranges 
without the user having to specify how many ports are required per run.
Something like:
    int basePort = getUserSpecifiedValue("baseport");
    String[] suiteNames = AllPackages.getTopLevelSuiteNames();
    // A smarter runner would use a port range pool, but this is just for 
illustration :)
    int[] basePorts = new int[suiteNames.length];
    for (int i=0; i < basePorts.length; i++) {
        basePorts[i] = basePort + (i * TestConfiguration.getMaxPortsUsed())
    }

This way, I don't have to update my parallel run-script when someone adds a new 
test that causes MAX_PORTS_USED to be incremented.


-- Kristian

> Would this be ok?
> 
> Tiago
> 
> 
> ----- Original Message ----
> From: Kristian Waagan<kristian.waagan@oracle.com>
> To: derby-dev@db.apache.org
> Sent: Wed, 14 July, 2010 10:06:54
> Subject: Re: regression test regressed
> 
> On 14.07.10 10:57, Tiago Espinha wrote:
> 
> [ snip ]
> 
>    
>> By having this constant and enforcing this limit, we can safely have a test
>>      
> run
>    
>> with basePort=1527 and another one with basePort=1538. If we were doing runs
>> like this and someone creates a new test that requires a new alternative port
>> (and if we didn't have the limit) then at some point the first run would be
>> using 1538 and our second run would also be using that at some point. We 
can't
>> say for sure that they will collide but the possibility exists.
>> 
>>      
> I wonder if we should make MAX_PORTS_USED public (maybe a public static
> method would be better), then parallel runners can configure the port
> ranges without any more help from the user than a base port.
> 
> 
>    


      


Mime
View raw message