Jaroslav Bachorik wrote:
On 21.2.2014 10:26, shanliang wrote:
Jaroslav Bachorik wrote:
Hi Shanliang,
On 20.2.2014 19:20, shanliang wrote:
Jaroslav,
The failed tests were:
1, 7, 8, 9
but the tests using this port (port2: 50235) were
1, 3, 4, 6, 7, 8, 9
and tests 2,4,6 were passed.
so I think that the problem might be that the port was not fully
released when a test was trying to use it, even the port was closed by
the previous test.
I don't think this is the case.
Firstly, test 1 fails. There are no previous tests possibly holding on
to the required port. So the port must have been taken by some foreign
process. The port number being from the ephemeral range doesn't help
either, quite contrary.
Secondly, a port can not be partially bound - either a process binds
to a port or not. Also, when a process exits all the bound ports must
be released. Since we are waiting for the exit code of the launched
test application before proceeding all the ports used by that
application must be released before the main test routine can continue.
Why did exception "Port already in use error: " happen for Test1, then
the port was free for 3/4/6, and then the exception appeared again for
7, 8, 9?
Test1: fails; it tries to start JMX connector on port 50235 and check
the conenction afterward
Test2: passes; does not use port 50235
Test3: passes; checks for not being able to connect to port 50235
Test4: fails; the same as Test1
Test5: passes; the same as Test2
Test6: fails; it tries to start RMI registry on port 50235 and fails
Test7: fails; the same as Test1
Test8: fails; the same as Test1
Test9: fails; the same as Test1
Test10: passes; the same as Test2
Test11: passes; the same as Test2
Test12: passes; the same as Test2
Test13: passes; the same as Test2
The port doesn't mysteriously become used and unused. It is still
occupied by a different process. Some of the tests don't fail simply
because they don't use the port.
Yes right, some tests passed because they did not expected JMX
connection, not sure possible to distinguish between a port issue and no
jmx server issue.
The fix looks OK.
Thanks,
Shanliang
A port is possibly unavailable after being closed, because it can be in
the state TIME_WAIT.
Your fix created a server socket but no client would connect to it, then
the port could be available immediately after close(), not need to enter
TIME_WAIT state, if so hopeful the fix could work.
SocketServer does not accept any incoming connection and as such the
socket should not go to TIME_WAIT state when it is closed. The JPRT
results would indicate that this is indeed the case.
-JB-
Shanliang
Your solution is to create a Server socket on a free port, then
release
it when a test needs it. I suspect whether we will fall into same
issue
here: the port would not be fully released when using it?
No. SocketServer.close() is called synchronously right before the port
is going to be used. This call unbinds the socket and returns. At the
moment of the return the port is free. I've run the tests locally and
via JPRT and they are all passing.
Thanks,
-JB-
Shanliang
Jaroslav Bachorik wrote:
Please, review this test fix.
Issue : https://bugs.openjdk.java.net/browse/JDK-8035395
Webrev: http://cr.openjdk.java.net/~jbachorik/8035395/webrev.00
Currently, the test is using two fixed ports to start JMX connector
and RMI registry when necessary. It can not deal with situations when
the ports are not available. The patch is adding the ability to
obtain
ports from the ephemeral range and use them instead of the hardcoded
ones. It also tries to minimize the chance of another process
stealing
the ports by holding the corresponding SocketServers open till right
before the port is actually needed.
Thanks,
-JB-
