RFR: JDK-8144144 - ORB destroy() leaks filedescriptors after unsuccessful connection
sean.coffey at oracle.com
Fri Jan 22 11:14:17 UTC 2016
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)
> On 20/01/2016 18:17, Seán Coffey wrote:
>> Hi Mark,
>> 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.
>> On 20/01/16 16:16, Mark Sheppard wrote:
>>> an update has been made to the webrev
>>> an anomaly was found in the select loop of the SelectorImpl.run()
>>> some defensive programming, for selector null references, have been
>>> added, also.
>>> On 08/01/2016 17:49, Mark Sheppard wrote:
>>>> please oblige and review the following changes
>>>> which addresses the issue
>>>> the changes ensure that an Acceptor and its associated
>>>> are closed.
More information about the core-libs-dev