db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <kristian.waa...@oracle.com>
Subject Re: regression test regressed
Date Wed, 14 Jul 2010 09:56:42 GMT
On 14.07.10 11:32, Tiago Espinha wrote:
> 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.
>    

I'm a bit skeptical about too many system properties, as they are 
inconvenient to maintain and use.
They're fine for special cases, but the test suite should run 
"out-of-the-box" if possible.

Your concern about something running on the bogus port already is valid, 
but we generally have the same issue with all ports we use - especially 
when the user specifies a base port.
We could try to connect a socket to the bogus port when creating the 
TestConfiguration, or maybe even when getBogusPort() is invoked, but I'm 
not sure it adds significant value. On the other hand, maybe the extra 
time spent doing so is negligible.

In my view, it is better to have a well-defined mechanism to get the 
bogus port, instead of doing getPort() -1 or something like that. I also 
think that the failure messages for connect tests should include the 
port number that was used, this makes it easier to debug.

Does this make sense, or is there a better solution?


Regards,
-- 
Kristian

> Tiago
>
>
> ----- Original Message ----
> From: Kristian Waagan<kristian.waagan@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.
>
>
>    


Mime
View raw message