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