db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <knut.hat...@oracle.com>
Subject Re: regression test regressed
Date Wed, 14 Jul 2010 09:31:29 GMT
On 07/14/10 10:57 AM, Tiago Espinha wrote:
> 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.

Thanks for explaining, Tiago. I suppose it would be safe to free a port
when NetworkServerTestSetup is torn down, but it seems like most of the
calls to getNextAvailablePort() come from the suite() methods, so
freeing the ports when the tests have completed won't be of much help.
(ServerPropertiesTest is the exception. It allocates four alternative
ports at runtime.)

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

Agreed. I don't think the issue here is that we use too many ports
(yet). It's just that it would be good if we didn't have to maintain a
max limit that developers may or may not discover that they need to
increase depending on how they ran the tests. This limit also has to be
maintained in the scripts the developers use to run the tests. So I
think it would be nice if we could somehow make the port allocation more
scalable, but I would be fine with just increasing the limit to, say, 20
for now.

Knut Anders

View raw message