RFR of JDK-8233313: server socket created by LocateRegistry.createRegistry(0) can not be closed

Hamlin Li huaming.li at oracle.com
Mon Nov 4 02:27:48 UTC 2019


Thanks Roger.

On 2019/11/1 11:14 PM, Roger Riggs wrote:
> Hi Hamlin,
>
> I would expect endPoint().getPort() to be non-zero except during the
> narrow window of the initialization before the server socket is opened.
> See TCPEndPoint.listen().

I assumed you mean TCPTransport.listen().

>
> If that's true, then either there is no server socket to close or
> that part of the condition is always true and could be removed.

TCPTransport.listen() is synced against TCPTransport instance, and 
decrementExportCount() is also synced against TCPTransport instance, so 
I agree we could just remove getListenPort()/getPort() check.

>
> So I think we'd need to understand if it was intentional to leave
> an application specified port open, while closing one that
> the application has no (specific) knowledge of.

I think it was intentional, reasons are:

1. check TCPTransport.setDefaultPort(...) ).

2. in code "r1 = LocateRegistry.createRegistry(0); 
UnicastRemoteObject.unexportObject(r1, true); r2 = 
LocateRegistry.createRegistry(0);", r1 and r1 use the same server socket 
port.

But I think we can/should change this behavior, reasons are:

1. it's not necessary, it's still a resource leak if I don't use port 0 
anymore.

2. it's not stated in the API doc.

3. if it's not stated in the API doc, then this behavior lead to 
inconsistency between 0 and other ports.

4. more important, this implementation makes some test scenarios hard to 
be stable (like JDK-8233105 
<https://bugs.openjdk.java.net/browse/JDK-8233105>).


Thank you

-Hamlin

>
> $.02, Roger
>
> BTW, verifyPortFree() would easier to understand and code with if it 
> returned a boolean
> instead throwing an exception.  The non-local exception handling makes 
> the code harder to follow.
>
>
>
> On 11/1/19 12:47 AM, Hamlin Li wrote:
>> Would you please to review the following patch?
>>
>> bug: https://bugs.openjdk.java.net/browse/JDK-8233313
>>
>> webrev: http://cr.openjdk.java.net/~mli/8233313/webrev.00/
>>
>> With following code, port used behind is not closed after unexportObject
>>
>> /Registry registry = LocateRegistry.createRegistry(0);//
>> //boolean b = UnicastRemoteObject.unexportObject(registry, true);/
>>
>> But, the port can be closed if pass in an explicit port number to 
>> createRegistry.
>>
>> I think is not right and is a resource leak.
>>
>>
>> Thank you
>>
>> -Hamlin
>>
>


More information about the core-libs-dev mailing list