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