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.
