JDK 9 RFR of JDK-8151582: (ch) test java/nio/channels/AsyncCloseAndInterrupt.java failing due to "Connection succeeded"

[Brian Burkhalter]

Hi Hamlin,

On Mar 9, 2016, at 9:55 PM, Hamlin Li <huaming.li at oracle.com> wrote:

> Thanks for point out this. My bad, I should have realized this earlier. In fact there are 2 kinds of issue mixed in original bug JDK-8068693.
>  1. one occurred only on windows, there are 5 failures, 1 failed against 6u101b10, 3 of them failed against 1.8.0_40, 1 failed against 1.9.0. The latest failure happened at at 2015-05-13 is against 6u101b10. The issue never happened since then.
> […]  
> 
> My current fix is just for the second issue as it happens so frequently recently, and I can make sure it's a test issue.
> To make the bug more clearer, I file a new bug to track the second issue, JDK-8151582
>> Secondly, the change in the backlog setting occurs in the initRefuser() method which is invoked only if TestUtil.onWindows() is false, i.e., the test is not being run on Windows. So one would think that the backlog change would have no effect on Windows.
> Yes, backlog are only used for CONNECT and FINISH_CONNECT tests which use initRefuser() and will not be run on windows.
>> Thirdly, if the test is being run with assertions enabled, then it appears that line 517 would throw an AssertionError on Windows and your changes at lines 523, 532, and 544-547 would never be executed.
> As said above, FINISH_CONNECT test is only run on non-windows, so the "assert" will not be executed on Windows. My change is only for FINISH_CONNECT test case failure which will not be run on windows.

Thanks for the clarifications.

>> Hopefully I am just misinterpreting something here.
> No, you helped to identify the bug description is not clear, thanks a lot.:-)

You’re welcome: I am glad it was useful.

> As I filed a new bug, would you please help to review it at new place:http://cr.openjdk.java.net/~mli/8151582/webrev.00/, only updated the bug id in the source code.
> bug: https://bugs.openjdk.java.net/browse/JDK-8151582

My only question is about AsyncCloseAndInterrupt.java line 92. If I recall correctly from my inspection of the code base last week, the default number of pending connections for ServerSocketChannel.bind(SocketAddress) is 50. Given the comment at line 509

// Create a pump thread dedicated to saturate refuser's connection backlog

I am wondering whether we want to go all the way down to a backlog of just one. Have you tried any other values in the range [2,50]?  It seems that with a queue length of only one the refuser’s connection backlog would be “almost always” saturated and I wonder whether that compromises the test somehow?

Thanks,

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