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:28:52 GMT
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.

Would this be ok?


----- 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 
> 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.


> I think the best and simplest way to solve this is to just bump up the limit 
> what's required right now. Even if we require 11 or 12 ports that still allows
> us, in theory, to have ~5000 parallel runs in the same machine, which would be
> madness even in a top-of-the-line server.
> Tiago
> ----- Original Message ----
> From: Knut Anders Hatlen<knut.hatlen@oracle.com>
> To: derby-dev@db.apache.org
> Sent: Wed, 14 July, 2010 9:34:48
> Subject: Re: regression test regressed
> On 07/14/10 09:24 AM, Tiago Espinha wrote:
>> It means that at some point in time during a suites.All run, each of the 
>> in the range [basePort, basePort+10] will be in use. They won't all be in use
>> at
>> the same time but we assume that any combination of them might be and as 
>> we know to keep away from that range for other parallel test runs.
> Thanks. Let me see if I understand... This means that we can't have more
> than 10 tests decorated with
> TestConfiguration.clientServerDecoratorWithAlternativePort() before we
> run out of ports? Could we somehow reclaim ports after a test has
> finished and make them available to subsequent tests so that we only run
> out of ports if a single test attempts to allocate more than 10 ports?


View raw message