db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tiago R. Espinha (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4217) Make the default port for the suites.All run configurable with a system property.
Date Tue, 16 Jun 2009 17:45:07 GMT

    [ 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.


Mime
View raw message