[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-serviceability-dev
Subject:    Re: RFR 8035395: sun/management/jmxremote/startstop/JMXStartStopTest.java
From:       shanliang <shanliang.jiang () oracle ! com>
Date:       2014-02-21 12:42:11
Message-ID: 530749A3.7060802 () oracle ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]