Review request for 7195249: Some jtreg tests use hard coded ports
Staffan Larsen
staffan.larsen at oracle.com
Wed Feb 26 06:36:11 PST 2014
On 26 feb 2014, at 15:24, taras ledkov <taras.ledkov at oracle.com> wrote:
> Hi,
>
> Alan, Mandy could you please review the fix: https://bugs.openjdk.java.net/browse/JDK-7195249.
>
> I had the discussion with Jaroslav and Staffan and they have approved my fix, but they are not reviewers.
I am a Reviewer.
Thanks,
/Staffan
>
> Webrev for jdk part:
> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
>
> Webrev for hs part:
> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.03/
>
> On 25.02.2014 17:52, Jaroslav Bachorik wrote:
>> Thumbs up. (not a "reviewer", though)
>>
>> -JB-
>>
>> On 19.2.2014 12:05, taras ledkov wrote:
>>> Hi,
>>>
>>> Imports are fixed:
>>>
>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.04/
>>>
>>> On 05.02.2014 17:20, Jaroslav Bachorik wrote:
>>>> Hi Taras,
>>>>
>>>> thanks for taking care of this.
>>>>
>>>> The changes look fine to me.
>>>>
>>>> One minor nit is unused imports of the library classes in
>>>> "test/sun/management/jmxremote/bootstrap/SSLConfigFilePermissionTest.java".
>>>>
>>>>
>>>> It does not use any of those classes as its base class
>>>> "AbstractFilePermissionTest" does all the heavy lifting.
>>>>
>>>> Cheers,
>>>>
>>>> -JB-
>>>>
>>>> On 5.2.2014 13:42, taras ledkov wrote:
>>>>> Hi,
>>>>>
>>>>> So please take a look at the review against JDK9.
>>>>> The reviewed patch had not been integrated into JDK8.
>>>>>
>>>>> Port to JDK9 is identical. The difference: the ProcessTools.java has
>>>>> been already patched by Jaroslav.
>>>>>
>>>>> Webrev for jdk part:
>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.03/
>>>>>
>>>>> Webrev for hs part:
>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.03/
>>>>>
>>>>>
>>>>> On 21.01.2014 13:45, Jaroslav Bachorik wrote:
>>>>>> Hi Taras,
>>>>>>
>>>>>> On 21.1.2014 10:30, taras ledkov wrote:
>>>>>>> Hi Jaroslav,
>>>>>>>
>>>>>>> Could you please review the last changes?
>>>>>>> Are you OK?
>>>>>>
>>>>>> Yes, the change looks ok. But I think we will need to get back to this
>>>>>> problem eventually and implement a central port dispatcher if we
>>>>>> want to
>>>>>> be 100% sure the port conflicts wouldn't occur. But your changes
>>>>>> reduce
>>>>>> the chance significantly.
>>>>>>
>>>>>> Thanks for taking care of this.
>>>>>>
>>>>>> -JB-
>>>>>>
>>>>>>>
>>>>>>> On 20.01.2014 19:21, Staffan Larsen wrote:
>>>>>>>> Sorry for not replying earlier. Yes, I’m ok with these changes.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> /Staffan
>>>>>>>>
>>>>>>>> On 20 jan 2014, at 16:07, taras ledkov <taras.ledkov at oracle.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Hi Staffan,
>>>>>>>>>
>>>>>>>>> I fixed the tests according with your comments.
>>>>>>>>> Are you OK?
>>>>>>>>>
>>>>>>>>> On 15.01.2014 19:15, taras ledkov wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please take a look at the new review.
>>>>>>>>>>
>>>>>>>>>> Webrev for jdk part:
>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.02/
>>>>>>>>>>
>>>>>>>>>> Webrev for hs part:
>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.02/
>>>>>>>>>>
>>>>>>>>>> My answers are inline:
>>>>>>>>>>
>>>>>>>>>> On 08.01.2014 17:46, Staffan Larsen wrote:
>>>>>>>>>>> Hi Taras,
>>>>>>>>>>>
>>>>>>>>>>> Thanks for doing this clean up and conversion of tests into Java.
>>>>>>>>>>> Here’s a couple of comments:
>>>>>>>>>>>
>>>>>>>>>>> test/runtime/6294277/SourceDebugExtension.java:
>>>>>>>>>>> This test could be simplified by not specifying an address at
>>>>>>>>>>> all.
>>>>>>>>>>> Since the test never connects to the JVM started with -Xrunjdwp,
>>>>>>>>>>> there
>>>>>>>>>>> is no reason to specify an address. If address is unspecified
>>>>>>>>>>> (and
>>>>>>>>>>> server=y), the connector will pick an address and print it to the
>>>>>>>>>>> command line. Thus the only change that needs to be done is to
>>>>>>>>>>> remove
>>>>>>>>>>> ",address=8888” from the @run command.
>>>>>>>>>> fixed
>>>>>>>>>>
>>>>>>>>>>> test/sun/management/jmxremote/bootstrap/RmiBootstrapTest.sh:
>>>>>>>>>>> test/sun/management/jmxremote/bootstrap/RmiSslBootstrapTest.sh:
>>>>>>>>>>> These tests do not compile cleanly with an empty JTwork
>>>>>>>>>>> directory. It
>>>>>>>>>>> seems that having one @build for each class does not work well -
>>>>>>>>>>> when
>>>>>>>>>>> compiling RmiBootstrapTest.java it cannot find TestLogger. Moving
>>>>>>>>>>> all
>>>>>>>>>>> classes to one @build statement solved this problem for me.
>>>>>>>>>> fixed
>>>>>>>>>>
>>>>>>>>>>> test/lib/testlibrary/jdk/testlibrary/ProcessTools.java:
>>>>>>>>>>> 187 Future<Void> stdoutTask = stdout.process();
>>>>>>>>>>> 188 Future<Void> stderrTask = stderr.process();
>>>>>>>>>>> The stdoutTask and stderrTask variables are unused.
>>>>>>>>>> fixed
>>>>>>>>>>
>>>>>>>>>>> test/sun/management/jmxremote/bootstrap/RmiRegistrySslTest.java:
>>>>>>>>>>> At first I thought something was wrong with this file - the
>>>>>>>>>>> diff is
>>>>>>>>>>> very weird. Then I realized you renamed an old file and created a
>>>>>>>>>>> new
>>>>>>>>>>> file using the old name.
>>>>>>>>>> You are right. I did it to keep the test name.
>>>>>>>>>>
>>>>>>>>>>> test/sun/management/jmxremote/bootstrap/AbstractFilePermissionTest.java:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> - Is resetPasswordFilePermission() really necessary? It looks
>>>>>>>>>>> like
>>>>>>>>>>> you
>>>>>>>>>>> delete the files at the beginning of the test in any case.
>>>>>>>>>> I think yes. n the first place, this functionality was at the old
>>>>>>>>>> code.
>>>>>>>>>> In the second place, a file without write permission may be a
>>>>>>>>>> problem
>>>>>>>>>> for a further cleanup (not by the test, for example for the tests
>>>>>>>>>> launcher scripts etc.)
>>>>>>>>>>
>>>>>>>>>>> - I find the names and usage of “mgmt” and “file2PermissionTest”
>>>>>>>>>>> confusing. They are both Paths. One is used directly by the
>>>>>>>>>>> sub-classes, the other has a getter method.
>>>>>>>>>> fixed
>>>>>>>>>>
>>>>>>>>>>> - Lines 57-58: Don’t swallow exceptions, add an
>>>>>>>>>>> ex.printStackTrace().
>>>>>>>>>>> (Same thing for all other places where you call
>>>>>>>>>>> Integer.parseInt())
>>>>>>>>>> fixed
>>>>>>>>>>
>>>>>>>>>>> test/sun/management/jmxremote/bootstrap/Dummy.java:
>>>>>>>>>>> This file is never used as far as I can see.
>>>>>>>>>> It is used by PasswordFilePermissionTest &
>>>>>>>>>> SSLConfigFilePermissionTest
>>>>>>>>>> via the AbstractFilePermissionTest (see the doTest method,
>>>>>>>>>> AbstractFilePermissionTest : 162).
>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> /Staffan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 26 dec 2013, at 14:09, taras ledkov <taras.ledkov at oracle.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>> Please take a look at the review with fixed issues about
>>>>>>>>>>>> trying to
>>>>>>>>>>>> launch test that needs free port several times.
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev for jdk part:
>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Webrev for hs part:
>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.01/
>>>>>>>>>>>>
>>>>>>>>>>>> Pay your attention to new method
>>>>>>>>>>>> ProcessTools.startProcess(String,
>>>>>>>>>>>> ProcessBuilder, Consumer<String>) that is used to analyze all
>>>>>>>>>>>> output
>>>>>>>>>>>> of a sub-process. It has common part with
>>>>>>>>>>>> ProcessTools.startProcess(String, ProcessBuilder,
>>>>>>>>>>>> Predicate<String>,
>>>>>>>>>>>> long, TumeUnit) that is used to determine the warm-up moment.
>>>>>>>>>>>>
>>>>>>>>>>>> I think the ProcessTools.startProcess(String, ProcessBuilder,
>>>>>>>>>>>> Predicate<String>, long, TumeUnit) may be changed by adding
>>>>>>>>>>>> LinePump
>>>>>>>>>>>> to stderr if there is not serious reason for restricting the
>>>>>>>>>>>> warm-up
>>>>>>>>>>>> analysis to stdout stream.
>>>>>>>>>>>>
>>>>>>>>>>>> On 10.12.2013 16:16, Yekaterina Kantserova wrote:
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've consulted with Serviceability engineers (add them to CC
>>>>>>>>>>>>> list) and
>>>>>>>>>>>>> they would like to see tests to solve these problem so far:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2. Implement loops in every test.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>> Katja
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 12/09/2013 11:02 AM, Alexandre (Shura) Iline wrote:
>>>>>>>>>>>>>> Guys.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Let me try to sum up what was said before and may be suggest a
>>>>>>>>>>>>>> compromise.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. There is a desire to have a support port allocation on the
>>>>>>>>>>>>>> level of
>>>>>>>>>>>>>> a JTReg suite execution. Taras created a bug for that
>>>>>>>>>>>>>> (https://bugs.openjdk.java.net/browse/JDK-7195249). Whether it
>>>>>>>>>>>>>> is a
>>>>>>>>>>>>>> test harness API or a library API does not really matter from
>>>>>>>>>>>>>> usage
>>>>>>>>>>>>>> point of view.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2. There is no way to make the tests absolutely stable,
>>>>>>>>>>>>>> whatever
>>>>>>>>>>>>>> port
>>>>>>>>>>>>>> allocation logic is used. The best we could do is to try to
>>>>>>>>>>>>>> perform
>>>>>>>>>>>>>> the test logic with different ports until the test succeeds.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Both arguments make sense. #2 is the ultimate answer, of
>>>>>>>>>>>>>> course,
>>>>>>>>>>>>>> but
>>>>>>>>>>>>>> better be used in conjunction with a meaningful port selection
>>>>>>>>>>>>>> algorithm.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At the same time, copying a loop-until-success login from one
>>>>>>>>>>>>>> test to
>>>>>>>>>>>>>> another may be not the best solution. Library could help with
>>>>>>>>>>>>>> that I
>>>>>>>>>>>>>> believe. There only need to be an API method which takes
>>>>>>>>>>>>>> behavior as a
>>>>>>>>>>>>>> parameter and run it until it succeeds. Something like:
>>>>>>>>>>>>>> public <T> runOnAFreePort(Function<T, Integer>)
>>>>>>>>>>>>>> or similar. There could be arguments of how/whether to
>>>>>>>>>>>>>> implement
>>>>>>>>>>>>>> it,
>>>>>>>>>>>>>> the solution would not work for shell tests, etc, but still
>>>>>>>>>>>>>> ...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With the tests in question though, we have a few options.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 1. Integrate tests as is. Get to it later after reaching
>>>>>>>>>>>>>> agreement in
>>>>>>>>>>>>>> the library, etc.
>>>>>>>>>>>>>> 2. Implement loops in every test.
>>>>>>>>>>>>>> 3. Wait for the library to be ready and only then integrate
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>> changes.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Please let us know which one is closer to your heart.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I personally prefer #1 for the reason that the changes already
>>>>>>>>>>>>>> supposed to make the tests more stable and also there are many
>>>>>>>>>>>>>> more
>>>>>>>>>>>>>> tests tests which use ports, so the scope of the problem is
>>>>>>>>>>>>>> bigger
>>>>>>>>>>>>>> than these.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Shura
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Taras,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I agree with the previous comments, that Utils.getFreePort()
>>>>>>>>>>>>>>> does not
>>>>>>>>>>>>>>> guarantee the port will be still free when you start your
>>>>>>>>>>>>>>> process.
>>>>>>>>>>>>>>> Unfortunately I don't think the library can do more. However,
>>>>>>>>>>>>>>> there is a
>>>>>>>>>>>>>>> solution.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Please, look at the
>>>>>>>>>>>>>>> *jdk/test/sun/tools/jstatd/JstatdTest.java
>>>>>>>>>>>>>>> tryToSetupJstatdProcess()*. In brief, the test will try to
>>>>>>>>>>>>>>> start a
>>>>>>>>>>>>>>> process with a free port and then check if
>>>>>>>>>>>>>>> /java.rmi.server.ExportException: Port already in use/ has
>>>>>>>>>>>>>>> been
>>>>>>>>>>>>>>> thrown.
>>>>>>>>>>>>>>> If yes, you have to retry.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>> Katja
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 12/02/2013 01:39 PM, taras ledkov wrote:
>>>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Whatever logic is to be chosen to select a free port, it is
>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>> library responsibility to implements it, would not you
>>>>>>>>>>>>>>>> agree?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hence what I am suggesting is to integrate the tests as is.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Should we decide to replace logic of the port selection, we
>>>>>>>>>>>>>>>> could do
>>>>>>>>>>>>>>>> it later in the library.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 21.11.2013 15:00, Jaroslav Bachorik wrote:
>>>>>>>>>>>>>>>>> On 20.11.2013 18:38, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>>>>> Roger,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As soon as we close a socket nobody can guarantee that the
>>>>>>>>>>>>>>>>>> port is
>>>>>>>>>>>>>>>>>> free.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Moreover, port returned by getFreePort()[1] remains not
>>>>>>>>>>>>>>>>>> accessible
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> some time - it depends to system setup, take a look to
>>>>>>>>>>>>>>>>>> discussions
>>>>>>>>>>>>>>>>>> around SO_REUSEPORT for Linux or SO_REUSEADDR and
>>>>>>>>>>>>>>>>>> SO_LINGER
>>>>>>>>>>>>>>>>>> for
>>>>>>>>>>>>>>>>>> BSD.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So from stability point of view it's better to just return
>>>>>>>>>>>>>>>>>> random
>>>>>>>>>>>>>>>>>> number
>>>>>>>>>>>>>>>>>> between 49152 and 65535.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Well, this doesn't seem to improve the odds by much. When
>>>>>>>>>>>>>>>>> there are
>>>>>>>>>>>>>>>>> more
>>>>>>>>>>>>>>>>> tests run in parallel, all of them requiring a free port,
>>>>>>>>>>>>>>>>> nothing
>>>>>>>>>>>>>>>>> prevents the random function to return the same port to
>>>>>>>>>>>>>>>>> all of
>>>>>>>>>>>>>>>>> them.
>>>>>>>>>>>>>>>>> Also, two subsequent requests can return the same port and
>>>>>>>>>>>>>>>>> cause
>>>>>>>>>>>>>>>>> problems with timing when a port used by a previous test is
>>>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> fully
>>>>>>>>>>>>>>>>> ready to be assigned to a different socket. And as Dmitry
>>>>>>>>>>>>>>>>> pointed out
>>>>>>>>>>>>>>>>> unless one can keep hold of the allocated socket and use it
>>>>>>>>>>>>>>>>> later
>>>>>>>>>>>>>>>>> there
>>>>>>>>>>>>>>>>> is no guarantee that a port which was tested unallocated
>>>>>>>>>>>>>>>>> will
>>>>>>>>>>>>>>>>> remain
>>>>>>>>>>>>>>>>> unallocated also for the next few milliseconds.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The only fail proof solution would be a port allocating
>>>>>>>>>>>>>>>>> service
>>>>>>>>>>>>>>>>> provided
>>>>>>>>>>>>>>>>> by the harness. Until then we can only (hopefully) decrease
>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> chance
>>>>>>>>>>>>>>>>> of intermittent failures due to a port being in use.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -JB-
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> [1]
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 141 public static int getFreePort() throws
>>>>>>>>>>>>>>>>>> InterruptedException,
>>>>>>>>>>>>>>>>>> IOException {
>>>>>>>>>>>>>>>>>> 142 int port = -1;
>>>>>>>>>>>>>>>>>> 143
>>>>>>>>>>>>>>>>>> 144 while (port <= 0) {
>>>>>>>>>>>>>>>>>> 145 Thread.sleep(100);
>>>>>>>>>>>>>>>>>> 146
>>>>>>>>>>>>>>>>>> 147 ServerSocket serverSocket = null;
>>>>>>>>>>>>>>>>>> 148 try {
>>>>>>>>>>>>>>>>>> 149 serverSocket = new ServerSocket(0);
>>>>>>>>>>>>>>>>>> 150 port = serverSocket.getLocalPort();
>>>>>>>>>>>>>>>>>> 151 } finally {
>>>>>>>>>>>>>>>>>> 152 serverSocket.close();
>>>>>>>>>>>>>>>>>> 153 }
>>>>>>>>>>>>>>>>>> 154 }
>>>>>>>>>>>>>>>>>> 155
>>>>>>>>>>>>>>>>>> 156 return port;
>>>>>>>>>>>>>>>>>> 157 }
>>>>>>>>>>>>>>>>>> 158
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 2013-11-20 19:40, roger riggs wrote:
>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> fyi, The jdk.testlibrary.Utils.getFreePort() method will
>>>>>>>>>>>>>>>>>>> Open an
>>>>>>>>>>>>>>>>>>> free
>>>>>>>>>>>>>>>>>>> Socket, close it and return
>>>>>>>>>>>>>>>>>>> the port number.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> And as Alan recommended, use (0) when possible to have
>>>>>>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>> system
>>>>>>>>>>>>>>>>>>> assign
>>>>>>>>>>>>>>>>>>> the port #.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Roger
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On 11/20/2013 8:04 AM, Dmitry Samersoff wrote:
>>>>>>>>>>>>>>>>>>>> Taras,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> *The only* correct way to take really free port is:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1. Chose random number between 49152 and 65535
>>>>>>>>>>>>>>>>>>>> 2. Open socket
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> if socket fails - repeat step 1
>>>>>>>>>>>>>>>>>>>> if socket OK - return *socket*
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If you can't keep the socket open (e.g. you have to pass
>>>>>>>>>>>>>>>>>>>> port
>>>>>>>>>>>>>>>>>>>> number as
>>>>>>>>>>>>>>>>>>>> property value) you shouldn't do any pre-check as it
>>>>>>>>>>>>>>>>>>>> has no
>>>>>>>>>>>>>>>>>>>> value
>>>>>>>>>>>>>>>>>>>> - as
>>>>>>>>>>>>>>>>>>>> as soon as you close socket someone can take the port.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> So just choose a random number within the range above
>>>>>>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>>>>> let
>>>>>>>>>>>>>>>>>>>> networking
>>>>>>>>>>>>>>>>>>>> code opening socket to handle port conflict.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -Dmitry
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On 2013-11-20 15:54, taras ledkov wrote:
>>>>>>>>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am working on bug
>>>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-7195249.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> There are two webrevs:
>>>>>>>>>>>>>>>>>>>>> Webrev for jdk part:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/jdk/webrev.00/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Webrev for hs part:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~anazarov/7195249/hs/webrev.00/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Please take a look at some notes:
>>>>>>>>>>>>>>>>>>>>> - After discussing with Yekaterina Kantserova &
>>>>>>>>>>>>>>>>>>>>> Jaroslav
>>>>>>>>>>>>>>>>>>>>> Bachorik
>>>>>>>>>>>>>>>>>>>>> some
>>>>>>>>>>>>>>>>>>>>> shell tests have been converted to java based tests
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - PasswordFilePermissionTest &
>>>>>>>>>>>>>>>>>>>>> SSLConfigFilePermissionTest
>>>>>>>>>>>>>>>>>>>>> tests
>>>>>>>>>>>>>>>>>>>>> looked
>>>>>>>>>>>>>>>>>>>>> very similar, so a common parent class was created for
>>>>>>>>>>>>>>>>>>>>> them:
>>>>>>>>>>>>>>>>>>>>> AbstractFilePermissionTest
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - What was called RmiRegistrySslTest.java I've
>>>>>>>>>>>>>>>>>>>>> renamed to
>>>>>>>>>>>>>>>>>>>>> RmiRegistrySslTestApp.java. The java code to replace
>>>>>>>>>>>>>>>>>>>>> old
>>>>>>>>>>>>>>>>>>>>> shell
>>>>>>>>>>>>>>>>>>>>> script
>>>>>>>>>>>>>>>>>>>>> RmiRegistrySslTest.sh is called
>>>>>>>>>>>>>>>>>>>>> RmiRegistrySslTest.java,
>>>>>>>>>>>>>>>>>>>>> hence the
>>>>>>>>>>>>>>>>>>>>> huge
>>>>>>>>>>>>>>>>>>>>> diff.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - The new RmiRegistrySslTest.java has some lines
>>>>>>>>>>>>>>>>>>>>> similar
>>>>>>>>>>>>>>>>>>>>> to the
>>>>>>>>>>>>>>>>>>>>> AbstractFilePermissionTest.java, I nevertheless decided
>>>>>>>>>>>>>>>>>>>>> to not
>>>>>>>>>>>>>>>>>>>>> complicate the code further and leave it as is. Please
>>>>>>>>>>>>>>>>>>>>> let me
>>>>>>>>>>>>>>>>>>>>> know if
>>>>>>>>>>>>>>>>>>>>> this is somehow not acceptable
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - com/oracle/java/testlibrary/Utils.java that is
>>>>>>>>>>>>>>>>>>>>> added to
>>>>>>>>>>>>>>>>>>>>> hotspot
>>>>>>>>>>>>>>>>>>>>> repository is taken from this patch:
>>>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~ykantser/8023138/webrev.00/test/lib/testlibrary/jdk/testlibrary/Utils.java.sdiff.html
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> - These tests will need additional changes when test
>>>>>>>>>>>>>>>>>>>>> library
>>>>>>>>>>>>>>>>>>>>> process
>>>>>>>>>>>>>>>>>>>>> tools will support command line options inheritance
>>>>>>>>>>>>>>>>>>>>> (http://mail.openjdk.java.net/pipermail/serviceability-dev/2013-November/013235.html)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> With best regards,
>>>>>>>>>>>> Taras Ledkov
>>>>>>>>>>>> Mail-To: taras.ledkov at oracle.com
>>>>>>>>>>>> skype: taras_ledkov
>>>>>>>>>>>> Phone: 7(812)3346-157
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> With best regards,
>>>>>>>>> Taras Ledkov
>>>>>>>>> Mail-To: taras.ledkov at oracle.com
>>>>>>>>> skype: taras_ledkov
>>>>>>>>> Phone: 7(812)3346-157
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
> --
> With best regards,
> Taras Ledkov
> Mail-To: taras.ledkov at oracle.com
> skype: taras_ledkov
> Phone: 7(812)3346-157
More information about the serviceability-dev
mailing list