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

[Jaroslav Bachorik]

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.

>
> 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-
>>>
>>
>