8203765: java/nio/channels/Selector/SelectAndClose: add some prints and @intermittent tag

Alan Bateman Alan.Bateman at oracle.com
Thu May 24 07:34:39 UTC 2018


On 24/05/2018 00:51, Brian Burkhalter wrote:
> https://bugs.openjdk.java.net/browse/JDK-8203765
> http://cr.openjdk.java.net/~bpb/8203765/webrev.00/
>
> This test-only change modifies the information printed on failure and adds the @intermittent tag as the test fails occasionally albeit rarely.
>
I assume the issue with the test is that closeThread closes the Selector 
before selectThread calls select and this leads to the 
ClosedSelectorException. The test gives selectThread two seconds to 
block in select and it seems this is not enough on some (overloaded?) 
test systems.

One suggestion is to "poll" the selectThread to see if it has locked the 
selector's selected key set with something like:

while (!mayHoldLock(selectThread, selector.selectedKeys())) {
     Thread.sleep(50);
}

where mayHoldLock gives some confidence that it is indeed locking the 
selected key set:

     boolean mayHoldsLock(Thread t, Object lock) {
         long tid = t.getId();
         int hash = System.identityHashCode(lock);
         ThreadInfo ti = 
ManagementFactory.getThreadMXBean().getThreadInfo(new long[]{ tid} , 
true, false, 100)[0];
         if (ti != null) {
             for (MonitorInfo mi : ti.getLockedMonitors()) {
                 if (mi.getIdentityHashCode() == hash)
                     return true;
             }
         }
         return false;
     }

If that works then you'll know that selectThread is in the select method 
and more importantly, it is past the check if the channel is closed.

Another suggestion is to get rid of closeThread. I checked the original 
(JDK 1.4.x era) issue and it only needs two threads to create the 
conditions for the original bug. The main thread can be one of those.

-Alan


More information about the nio-dev mailing list