RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java fails intermittently: Port already in use (original) (raw)

shanliang shanliang.jiang at oracle.com
Fri Feb 21 04:42:11 PST 2014

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 TIMEWAIT. 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 TIMEWAIT state, if so hopeful the fix could work. SocketServer does not accept any incoming connection and as such the socket should not go to TIMEWAIT 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-

More information about the serviceability-dev mailing list