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? Tiago ----- Original Message ---- From: Kristian Waagan <[email protected]> To: [email protected] 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. -- Kristian > 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<[email protected]> > To: [email protected] > 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? > >
