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

[Dmitry Samersoff]

Jaroslav,

Generally speacking - test getting port number from command line should
get it from harness and harness have to maintain a pool of free ports.

But it's a long term goal.

Today we don't have better option than chose a random number and hope
this port is free.

Any pre-check just sligthly decrease the probability of conflict at the
cost of waisting time and resources.

-Dmitry



On 2013-11-20 17:42, Jaroslav Bachorik wrote:
> 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)
>>>
>>>
>>>
>>
>>
> 


-- 
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.