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

[Hamlin Li]

On 2016/3/15 6:14, Brian Burkhalter wrote:
> Hi Hamlin,
>
> On Mar 9, 2016, at 9:55 PM, Hamlin Li <huaming.li at oracle.com 
> <mailto: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 
>> bugJDK-8068693 <https://bugs.openjdk.java.net/browse/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 <https://bugs.openjdk.java.net/browse/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?
Hi Brian,

Please let me clarify it: Even with backlog set to 1, there will be more 
than 1 successful connections on some platforms, for example linux, and 
it will grow very slowly, the test results on my local verify this. And, 
even if on some other platforms there is only 1 connection totally in 
the complete and incomplete queues, it will not do harm to test, because 
what we want refuser server to do is to reject connections from any 
clients except the earliest connection[s] from pump thread before 
refuser server is saturated. I think it's better to set backlog of 
refuser server as 1, so we can make refuser's complete and incomplete 
queues saturated as quickly as possible by pump thread, and it will be 
more possible for pump thread to make sure saturate the queues.
Not sure if clarification above is clear enough, please let me know your 
further concerns. :-)

Thank you
-Hamlin
>
> Thanks,
>
> Brian

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