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

[Alan Bateman]

On 06/03/2018 08:39, Hamlin Li wrote:
>
> Hi Alan,
>
> I have minor comment about CloseDuringConnect.java, is it better to 
> move following code from main() to test()?
>
> SocketAddress remote = new InetSocketAddress("127.0.0.1", Utils.getFreePort());
>
> It will reduce the chance to interfere with other tests which run 
> concurrently and also create a listening socket at THE free port same 
> as this test.
>
Good question! There is a general issue with tests that need a free 
port, or a refusing endpoint in this case. Ideally jtreg would support a 
per test equivalent of exclusiveAccess.dirs, that way tests can at least 
reduce interference from tests that execute concurrently without needing 
to put the test in a special directory.

The issue with Utils.getFreePort in the test infrastructure library is 
that it sleeps for 100ms. This test results makes 100 attempts to 
connect to a refusing endpoint so calling getFreePort before each 
attempt adds significantly to the execution time. Would you have cycles 
to check into the getFreePort implementation? I suspect the original 
rational was to handle cases where the system is out of resources but it 
doesn't catch IOException and sleeps before the first attempt. I didn't 
want to change it with this patch as it is used by a lot of other tests.

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.

-Alan


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180306/18665941/attachment.html>