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 08:57:50 GMT
At this point port reclaiming is not possible but it's just a matter of creating 
another method in TestConfiguration that decrements the number of ports used so 
far. If you are 100% positive that the latest port requested isn't going to be 
used again by the test, then I guess you could "free" it. Say you've started on 
port 20000 and you've just got 20001 for the current test. If at the end of the 
test you are sure that 20001 won't be used again by that test, you could 
decrement the last assigned port to 20000 and as such, the next port that will 
be assigned to other tests will be 20001 again.

This might be dangerous when it comes to replication (I think it is replication 
that uses this) because at the same point in time we will have multiple ports 
allocated to different instances of Derby and then it is essential that they 
don't overlap.

In response to what you said, yes, it does mean that we can't have more than 10 
tests decorated using that method but at a more lower level, what it actually 
means is that we cannot invoke getAlternativePort() more than 10 times. But this 
constant isn't an actual limit, it's just the number of ports I've found to be 
needed when I implemented this mechanism. It was a quick way to deal with the 
fact that we have tests that require alternative ports that can't overlap. Since 
the ports are sequenced based on a basePort, it also means we can safely have 
parallel runs without the risk of port collision.

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 think the best and simplest way to solve this is to just bump up the limit to 
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 ports 

> 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 such, 

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

-- 
Knut Anders


      


Mime
View raw message