RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection

[Chris Hegarty]

On 11/01/16 10:39, Mark Sheppard wrote:
> OK thanks Chris
>
> my observation was that if only  channel.close()  was invoked then
> the underlying serversocket was not being closed, it remained in the
> LISTEN state.
> This was on Windows 7.

It is not necessary to call close() on the Socket adapter,
after channel.close() has been called.

Alan just reminded me that, on some platforms ( Windows ) the
underlying socket may remain open, if registered with a selector,
even after calling closed, until the the selector fires. This may
help explain why you seen the above behavior.

-Chris.

> I'll check this again  ...
>
> regards
> Mark
>
> On 11/01/2016 06:32, Chris Hegarty wrote:
>> On 8 Jan 2016, at 17:49, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>
>>> Hi
>>>    please oblige and review the following changes
>>> http://cr.openjdk.java.net/~msheppar/8144144/webrev/
>> In SelectorImpl.clearDeferredRegistrations() there is no need to call
>> close()
>> on the Socket returned from channel.socket(), since you have already
>> closed the channel.
>>
>> -Chris.
>>
>>> which addresses the issue
>>> https://bugs.openjdk.java.net/browse/JDK-8144144
>>>
>>> the changes ensure that an Acceptor and its associated
>>> ServerSocket/ServerSocketChannel
>>> are closed.
>>>
>>> regards
>>> Mark
>