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)
