You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Kristian Waagan (JIRA)" <ji...@apache.org> on 2010/07/01 11:01:57 UTC
[jira] Updated: (DERBY-4700) Add method to obtain a bogus port in
TestConfiguration
[ https://issues.apache.org/jira/browse/DERBY-4700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kristian Waagan updated DERBY-4700:
-----------------------------------
Attachment: derby-4700-1b.diff
Thanks, Dag.
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?
What about a JMX port?
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.
Re: [jira] Updated: (DERBY-4700) Add method to obtain a bogus port in TestConfiguration
Posted by "Dag H. Wanvik" <da...@oracle.com>.
"Kristian Waagan (JIRA)" <ji...@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.
>
--