[
https://issues.apache.org/jira/browse/DERBY-4217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720256#action_12720256
]
Tiago R. Espinha commented on DERBY-4217:
-----------------------------------------
You are right Kathey, that's a typo on my end. However, since we will probably
change things a bit regarding the alternative ports, that patch will stay on
hold.
So, the cleaner implementation would imply having a getNextAvailablePort()
method in TestConfiguration that would replace our getAlternativePort().
I think that ideally we'd even only allow for the base port to be set and then
every other port would build on that by offsetting from the base port. Each
time we'd invoke getNextAvailablePort(), we would get an usable port for our a
server. Do note that the base port remains fixed throughout the suite run; it
is just alternative ports (replication ports, jmx, actual alternative ports
that some tests like ServerPropertiesTest require) that would build on upon the
base port.
We would have no real offset, the alternative ports would be assigned on the go
with lastAvailablePort+1.
Also, Kathey suggested we would create a constant under TestConfiguration named
MAX_PORTS_USED, which would tell us the maximum number of alternative ports
that can be assigned. This constant would then be used in
getNextAvailablePort() in an assert - if the port being requested is over the
limit of ports that can be used, it would mean that a new test that uses an
alternative port had been added and so the developer would have to update the
constant and the wiki page. (This is an attempt to make sure that the wiki page
on concurrent test runs is always up-to-date, and that people running
concurrent runs always know how many ports they should leave between runs)
To finalize, with this idea, the concept of alternative port is lost. Or better
said, it merges with the concept of JMX and replication ports since those would
also be obtained through the getNextAvailablePort().
It might be too restrictive to only allow the base port to be set, but I think
we would be able to keep it simple this way. If we allow JMX, or replication
(or both) ports to be set through properties, then this concept might not be
the ideal; and honestly, from a developer perspective, I think it is much
straightforward if we only have to set the base port and know that the
concurrent run just has to be X ports away from the first run.
> Make the default port for the suites.All run configurable with a system
> property.
> ---------------------------------------------------------------------------------
>
> Key: DERBY-4217
> URL: https://issues.apache.org/jira/browse/DERBY-4217
> Project: Derby
> Issue Type: Sub-task
> Affects Versions: 10.6.0.0
> Reporter: Tiago R. Espinha
> Assignee: Tiago R. Espinha
> Attachments: DERBY-4217-dtap.patch, DERBY-4217-dtap.patch,
> DERBY-4217-dtp.patch, DERBY-4217-dtp.patch, DERBY-4217-dtp.patch,
> DERBY-4217-dtp.patch, DERBY-4217-dtp.patch, DERBY-4217-ij.patch,
> DERBY-4217-ij.patch, DERBY-4217-ij.patch, DERBY-4217-ij.patch,
> DERBY-4217-ij.patch, DERBY-4217-ij.stat, DERBY-4217-ij.stat,
> DERBY-4217.patch, DERBY-4217.patch, DERBY-4217.patch, DERBY-4217.patch,
> DERBY-4217.stat, DERBY-4217.stat, ErrorLog_suitesAll_bound.tgz,
> ReproNetworkServerControl.java
>
>
> The goal is to make the port used for suites.All configurable through a
> system property passed on to the JVM.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
