Review request for 7195249: Some jtreg tests use hard coded ports
taras ledkov
taras.ledkov at oracle.com
Thu Feb 27 03:39:38 PST 2014
Staffan, Excuse me.
I didn't know about that.
I looked at the http://openjdk.java.net/census#serviceability.
Now I'm in need of the second review.
On 26.02.2014 18:36, Staffan Larsen wrote:
>
> 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
>
--
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