Review request for 7195249: Some jtreg tests use hard coded ports

[Jaroslav Bachorik]

On 20.11.2013 14:04, 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.

The problem is that the majority of the uses here is passing the port as 
an argument to the external application. There is no chance of 
forwarding the allocated socket.

I've tried to experiment with the code that would try to "discover" a 
free port for the external application (eg. starting the application 
with random ports until it does not report any binding related exception 
and then returning the port back to the caller). It is achievable but 
relatively a lot of work - not sure how well this fail-proof system 
would measure against picking random ports and relying on the chance of 
the chosen port not being swept away by another process.

-JB-

>
> -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)
>>
>>
>
>