The AcceptingChannel<StreamConnection> created by Endpoint.getConnectionProviderInterface(...).createServer(...) does not synchronously close down the underlying socket as part of a call to its close() method. The result is if the application wishes to create a new server there is a race between that creation and the async close of the previous server.

I believe this race is the cause of the intermittent WildFly Core testsuite failures discussed in WFCORE-3302.

The socket is not closed synchronously because the ServerSocketChannel impl of close() does not close the socket if there are any registered keys. Debugging shows the socket is not closed until this stack happens:

"XNIO-1 Accept@1562" daemon prio=5 tid=0xf nid=NA runnable
  java.lang.Thread.State: RUNNABLE
	  at sun.nio.ch.ServerSocketChannelImpl.kill(ServerSocketChannelImpl.java:307)
	  - locked <0xc0d> (a java.lang.Object)
	  at sun.nio.ch.KQueueSelectorImpl.implDereg(KQueueSelectorImpl.java:229)
	  at sun.nio.ch.SelectorImpl.processDeregisterQueue(SelectorImpl.java:149)
	  - locked <0xc38> (a java.util.HashSet)
	  at sun.nio.ch.KQueueSelectorImpl.doSelect(KQueueSelectorImpl.java:107)
	  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:86)
	  - locked <0xc2b> (a sun.nio.ch.KQueueSelectorImpl)
	  - locked <0xc39> (a java.util.Collections$UnmodifiableSet)
	  - locked <0xc3a> (a sun.nio.ch.Util$2)
	  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:97)
	  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:101)
	  at org.xnio.nio.WorkerThread.run(WorkerThread.java:519)

That worker thread is not under the control of the application except by closing down the endpoint, which means unless the app is closing down the endpoint along with stopping the server there's a race.

In a moment I'll link a reproducer.