RFR for JDK-8031563: TEST_BUG: java/nio/channels/Selector/ChangingInterests.java failed once

michael cui michael.cui at oracle.com
Wed Feb 12 13:34:32 UTC 2014


Hi,

Please review two suggested fixes for

https://bugs.openjdk.java.net/browse/JDK-8031563

Root cause: selectNow is called right after 50 milliseconds sleep in 
write1 method which may not be sufficient to make the socket channel 
readable in some situation. Since selectNow called only once and 
verification based on its result will fail if readable event wasn't 
ready at that time.


Suggested fix A : simply increase the wait time from 50 to 1000 in 
write1() method.
webrev link : 
http://cr.openjdk.java.net/~tyan/michael/JDK-8031563/webrev_v1/ 
<http://cr.openjdk.java.net/%7Etyan/michael/JDK-8031563/webrev_v1/>
Comments from Shura :
           Simply increasing the timeout will not fix the problem forever.
           Is it possible to re-write the tests so that the channel is 
waited to be readable instead?


Suggested fix B : In testChange() , replacing original [select - verify] 
block by [wait - select - until verify or timeout] block.
webrev link : 
http://cr.openjdk.java.net/~tyan/michael/JDK-8031563/webrev_v2/ 
<http://cr.openjdk.java.net/%7Etyan/michael/JDK-8031563/webrev_v2/>

Explanation :

Test will fail intermittently when interest setting are (OP_READ | 
OP_WRITE). The goal is waiting until interested event coming or timeout. 
However, interest setting is OP_READ | OP_WRITE, so the blocking version 
api select() / select(long timeout) will return immediately as long as 
one of interested type event is ready (see selector class api). 
Moreover, SocketChannel is always writable if its internal buffer 
doesn't full. So all selection api will return immediately when interest 
setting contains OP_WRITE.

So based on selector's api explanation and my testing, it is impossible 
to implement [wait - select - until verify or timeout] logic without 
using loop.

The verification logic is adjusted slightly for while - loop.

Another thing I would like to mention is the selector's selected-key set 
will be updated only by selection or manually remove. In other words,
the selector.selectedKeys()  will only reflect io events of last select 
operation even if a new interested event has arrived right after last 
selection.

Comments from Shura :
           I have concern about two areas which might make your version 
and original version not equivalent.
           one is  code changes in verification logic are different.
           the other is old version called selectNow() only once, your 
version replace it by calling it repeatedly in worst case.

Both fixes were tested on 4 platforms (win, linux, mac, solaris)for 2000 
runs without seeing any error.

Any suggestion?


Thanks,
Michael Cui



More information about the core-libs-dev mailing list