Review request for 7195249: Some jtreg tests use hard coded ports
dmitry.samersoff at oracle.com
Wed Nov 20 05:59:09 PST 2013
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.
On 2013-11-20 17:42, Jaroslav Bachorik wrote:
> On 20.11.2013 14:04, Dmitry Samersoff wrote:
>> *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.
>> 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:
>>> Webrev for hs part:
>>> 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:
>>> - 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
>>> - 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:
>>> - These tests will need additional changes when test library process
>>> tools will support command line options inheritance
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
More information about the serviceability-dev