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

[Seán Coffey]

On 21/01/16 17:45, Mark Sheppard wrote:
> Thanks Sean
>
> i can revert the isClosed(), I put them in to make the access consistent
I'd question if the synchronized isClosed() and setClosed(boolean) 
helper methods are needed at all. The volatile closed boolean variable 
should be enough to manage this state flag. Either way, I don't think 
the synchronization around the closed variable is root cause of this 
issue and performance issues could be addressed in another change if 
necessary (playing safe)

regards,
Sean.

>
> regards
> Mark
>
> On 20/01/2016 18:17, Seán Coffey wrote:
>> Hi Mark,
>>
>> SelectorImpl.java:
>>
>> line 125, could you use a 2 arg method call to dprint. It'll print 
>> the stacktrace instead :
>> dprint(".close: selector.close: " + t);  --> dprint(".close: 
>> selector.close",  t);
>>
>> The "while (!isClosed()) " change introduces a new hot lock on closed 
>> variable. Hopefully, it won't impact performance too much.
>>
>> Looks good to me otherwise.
>>
>> Regards,
>> Sean.
>>
>> On 20/01/16 16:16, Mark Sheppard wrote:
>>> Hi,
>>>    an update has been made to the webrev
>>>
>>> http://cr.openjdk.java.net/~msheppar/8144144/webrev.03/
>>>
>>> an anomaly was found in the select loop of the SelectorImpl.run() 
>>> method
>>> some defensive programming, for selector null references, have been 
>>> added, also.
>>>
>>> regards
>>> Mark
>>>
>>> On 08/01/2016 17:49, Mark Sheppard wrote:
>>>> Hi
>>>>    please oblige and review the following changes
>>>> http://cr.openjdk.java.net/~msheppar/8144144/webrev/
>>>>
>>>> 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
>>>
>>
>