On 14.07.10 10:59, Tiago Espinha wrote:
A-ha I see what you mean. This limit is indeed for suites.All, so indeed it
wouldn't come up when individual suites are ran.
I'm not sure what you meant by bogus port though?
The bogus port is a port where no Derby network server (or anything
else) is running.
It is used for negative connect tests and such, for instance trying to
ping a network server on a port where there is no network server.
--
Kristian
Tiago
----- Original Message ----
From: Kristian Waagan<kristian.waa...@oracle.com>
To: derby-dev@db.apache.org
Sent: Wed, 14 July, 2010 8:52:32
Subject: Re: regression test regressed
On 13.07.10 22:33, Tiago Espinha wrote:
I think ideally we'd keep the max number of ports on a tight fit to what is
actually needed, that's why I left them at 10. This way if new ports are
required along the way, whoever makes the changes gets alerted that they need
to
increase this constant.
Of course we can also overshoot and give it a large margin and possibly never
get alerted by it again but I tend to prefer the tight fit approach. If we are
introducing tests that require more ports, it's a good idea to alert the
developer that it might have some repercussions in terms of parallel runs and
of
how far apart the port ranges should be.
I agree with this reasoning. After all, only a few tests are actually
requesting additional ports.
It's interesting though, even if you define a base port through a property,
this
issue should still come up because you'll still be using more ports than the
max
allows...
That's true if you run all the suites in suites.All in serial, but when
you run tests in parallel each suite gets it's own TestConfiguration
(with its own base port).
Depending on which tests require an additional port (calling
getNextAvailablePort(), directly or indirectly), a parallel run may or
may not trigger the assert.
Returning to keeping the number of ports down, would it make sense to
store the bogus port in a static variable? This way, all the
TestConfiguration instances in a JVM would share the same port, which is
possible since it is reserved as a port where nothing is supposed to be
listening.
Regards,
