db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2419) Tighten encapsulation of state in TestConfiguration
Date Thu, 08 Mar 2007 19:31:24 GMT

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


Mime
View raw message