Oh I see, then yes I guess we could store it as a static variable. Might it not be an inconvenient though? What port would we set it to? What if someone is doing test runs and has something bound to the port we came up with? Maybe the ideal solution would be to use a system property as well... we could allocate the bogus port normally through the getAlternativePort() if no property is defined, or simply use the static variable if one is defined as a property.
Tiago ----- Original Message ---- From: Kristian Waagan <kristian.waa...@oracle.com> To: derby-dev@db.apache.org Sent: Wed, 14 July, 2010 10:09:23 Subject: Re: regression test regressed 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, >
