db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: [jira] Updated: (DERBY-4700) Add method to obtain a bogus port in TestConfiguration
Date Mon, 05 Jul 2010 18:10:55 GMT
"Kristian Waagan (JIRA)" <jira@apache.org> writes:

> I have attached patch 1b, where I reverted to the idom used elsewhere (the "" + was just
to shorten the line :) ), and I also added a println method in TestConfiguration (TC). Not
quite sure about it yet, but it did at least made it clear to me that we are creating two
TC instances - so we end up with two JMX ports and two bogus ports. I guess one is for the
embedded configuration, the other for the client.
>
> Do we need a bogus port for an embedded TC?

Well, I used one in the BootLockTest, for example (although Kathey has
later rewritten that test to work without ports), so I wouldn't rule
it a priori. I wasn't aware that we created two concurrent TCs either,
presumably they are used in sequence, so we don't *really* need separate
port assignements for them?

> What about a JMX port?

I think JMX is useful also for an embedded Derby, so we would want to
be able to test it.

Thanks,
Dag

>
> I'm a bit in a hurry right now, but will return to this later.
>
>> Add method to obtain a bogus port in TestConfiguration
>> ------------------------------------------------------
>>
>>                 Key: DERBY-4700
>>                 URL: https://issues.apache.org/jira/browse/DERBY-4700
>>             Project: Derby
>>          Issue Type: Improvement
>>          Components: Test
>>    Affects Versions: 10.7.0.0
>>            Reporter: Kristian Waagan
>>            Assignee: Kristian Waagan
>>            Priority: Minor
>>         Attachments: derby-4700-1a.diff, derby-4700-1b.diff
>>
>>
>> In some cases one needs to obtain a port number on which there is no Derby network
server.
>> Today this is solved in an ad-hoc way, for instance by using the current port minus
one. When running tests in parallel, there is a chance that a port where there actually is
a Derby network server listening is picked.
>> As a start, I suggest that the bogus port is allocated to the last port in the port
range configured for the run: baseport + MAX_PORTS_USED -1.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>

-- 

Mime
View raw message