8198928: (so) SocketChannel connect may deadlock if closed at around same time that connect fails

[Hamlin Li]

On 06/03/2018 10:14 PM, Alan Bateman wrote:
> On 06/03/2018 10:51, Hamlin Li wrote:
>>
>> :
>>
>>>
>>> In the mean-time, maybe we can address your concern by just 
>>> replacing the use of Utils.getFreePort in this test with its own 
>>> refusingEndpoint method. I've updated the webrev in place so you can 
>>> see if you agree. If we get Utils.getFreePort fixed then we can 
>>> replace this usage, probably other cases like this in other tests too.
>> For this test, I think another way is to use reserved/unused ports as 
>> the free port, e.g. port 1, port 4, ... [1]
> I agree as it seems unlikely that something will start a listener on a 
> system port (<1024) while the tests are running. For now, the 
> refusingEndpoint() method in the test probes the system ports. If the 
> test infrastructure library is updated to provide something better 
> than the current getFreePort then we can move it to use that.
Hi Alan,

It looks good to me.
And I think refusingEndpoint() is a good candidate to move into Utils 
class of testlibrary, I can do it when/if I make change for getFreePort.

Thank you
-Hamlin
>
> -Alan