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



Reply via email to