RFR of JDK-8134599: TEST_BUG: java/rmi/transport/closeServerSocket/CloseServerSocket.java fails intermittently with Address already in use

[Hamlin Li]

Thanks Roger!

On 2019/10/16 10:51 PM, Roger Riggs wrote:
> Hi Hamlin,
>
> Some additional logging that the socket has been closed might be 
> useful in TCPTransport.java.
>
> In particular,
>  -  in the decrementExportCount() method
>  -  in the closeSocket() method;
I agree, just created https://bugs.openjdk.java.net/browse/JDK-8232446 
to track this enhancement.
>
>
> With respect to Asynchronous...
>
> The call to unexport(force = true) is synchronous if the reference 
> count decrements to zero.
> So I'm a bit surprised that in this case there is an issue.
>
> (I added printf of the thread invoking unexport and the code doing the 
> ss.close(in TCPTransport)
> and it was the same thread with the messages in order.)
>
> The normal unexport(force = false) is async, since it needs the GC to 
> determine
> there are no references in the process and the ObjectTable.reaper thread
> to decrement all the counts and close the socket.
>
> The hard reference to Registry implementation in the CloseServerSocket 
> test
> shouldn't be an issue but depending on GC and optimizations, the GC 
> may or may not
> consider the value of the 'registry' variable to be alive after the 
> call to unexportObject().
> Setting it to null might remove that variable.

Thanks for the information.

I think it will be more clear when JDK-8232446 
<https://bugs.openjdk.java.net/browse/JDK-8232446> is finished, let see 
then. :-)

Thank you

-Hamlin

>
> On 10/16/19 1:28 AM, Hamlin Li wrote:
>>
>> Thanks Roger, sorry for that I missed your response. (most of time I 
>> focus on mail send to/cc me :) )
>>
>> On 2019/10/15 10:29 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> 1. Replace the creation of the Registry with 
>>> TestLibrary.crateRegistryOnEphemeralPort
>>> and call TestLibrary.getRegistryPort to get the port number.
>>>
>>> The intent of the test is still satisified without the timing/port 
>>> allocation issues.
>>
>> For this test, it failed only after unexportObject is called and port 
>> is not freed in time or occupied again by others.
>>
>> So it would be fine to use createRegistryOnEphemeralPort but will not 
>> help to resolve this issue.
>>
> ok, just cutting down on the variables
>>
>>>
>>> 2. Another approach to testing if the port is in use would be to
>>> assume its still active and do a registry.lookup("xxx").
>>>
>>> The response be NotBoundException if the registry is still alive
>>> or will be a RemoteException indicating the port is closed.
>>>
>>> If some other application has grabbed the port, some other exception 
>>> RemoteException cause will be thrown.
>>
>> I'm not sure if RemoteException equals to the port has been closed by 
>> the registry.
>>
>> Based on API doc, "|RemoteException 
>> <https://docs.oracle.com/en/java/javase/12/docs/api/java.rmi/java/rmi/RemoteException.html>|- 
>> if remote communication with the registry failed; if exception is 
>> a|ServerException|containing an|AccessException|, then the registry 
>> denies the caller access to perform this operation", in my 
>> understanding, a) "port is closed" and b) "others grab the port 
>> again" will cause RemoteException, but RemoteException does not mean 
>> it's in just one of the 2 situations a) and b).
>>
>
> I should have been more specific and to examine the exception that 
> caused the RemoteException.
> It should reflect the socket level error, if any.
>
> Roger
>
>> Thank you
>>
>> -Hamlin
>>
>>
>