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