RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection
chris.hegarty at oracle.com
Mon Jan 11 11:09:42 UTC 2016
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.
> I'll check this again ...
> On 11/01/2016 06:32, Chris Hegarty wrote:
>> On 8 Jan 2016, at 17:49, Mark Sheppard <mark.sheppard at oracle.com> wrote:
>>> please oblige and review the following changes
>> In SelectorImpl.clearDeferredRegistrations() there is no need to call
>> on the Socket returned from channel.socket(), since you have already
>> closed the channel.
>>> which addresses the issue
>>> the changes ensure that an Acceptor and its associated
>>> are closed.
More information about the core-libs-dev