[
https://issues.apache.org/jira/browse/DERBY-2419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12479415
]
Kristian Waagan commented on DERBY-2419:
----------------------------------------
I think I understand why the default hostname and port number were made public
now :)
The problem is that when you change to a client setup from an embedded setup,
you basically have no values to supply to the TestConfiguration constructor.
You can't use the values from the embedded setup, because they are 'null' and
-1. You definitely don't want to supply your own custom values, as this will
(possibly) mess up concurrent runs (for instance two suites.All on the same
machine).
I had a brief discussion offline with Dag, and we identified the following
scenarios wrt port numbers:
1) The default Derby port number (1527)
2) The default port number for the test run/configuration (as 1, or as
specified by user by a property)
3) A different port for running multiple servers in the same test (typically
as 2 with an offset)
Making the default Derby hostname and port public is not the right solution, as
this will make independent runs always use the same hostname/port and could
cause collision. Thus supporting only 1 is not a good solution.
By supporting option 2, and giving the user the possibility to override the
port number used by the tests, we allow independent test runs to execute in
parallel on a single machine. There are various implementation details here as
well, such as if the property should only be read when the TestConfiguration
class is loaded (static initializer block) or on instantiation. I prefer the
first, as the second can lead to strange failures if the port number is changed
"on-the-fly".
Option 3 is just a little extra, but as I don't think there is any use for it
yet (??), it can be left for later. It certainly require more thought to avoid
port usage to get out of control...
I have a few ideas for fixing this, but I need some more time with the initial
patch.
If people have comments on this issue, please put them forth so they can be
discussed and/or incorporated in the patch.
Note that there is a big difference between concurrent independent runs and
parallelizing the execution of the tests. In the latter you run tests in
parallel by invoking a single command and let the "harness" manage parallel
execution. This demands more elaborate port handling, and I have not registered
any community initiatives to implement parallel test execution.
> Tighten encapsulation of state in TestConfiguration
> ---------------------------------------------------
>
> Key: DERBY-2419
> URL: https://issues.apache.org/jira/browse/DERBY-2419
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Affects Versions: 10.3.0.0
> Reporter: Kristian Waagan
> Assigned To: Kristian Waagan
> Priority: Minor
>
> Parts of the state of TestConfiguration has been made public, which they
> should not be; DEFAULT_PORT and DEFAULT_HOSTNAME.
> Using these directly from the outside can cause settings overridden by the
> user to be ignored by tests. Further, a test should not care if the host/port
> it uses is the Derby default or the values set by the user running the test.
> To obtain a hostname and a port number, use the methods getPort and
> getHostName in TestConfiguration.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
