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

Roger Riggs Roger.Riggs at oracle.com
Wed Oct 16 14:51:37 UTC 2019


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;


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.

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



More information about the core-libs-dev mailing list