NioServer.stop() currently closes its server channel by invoking Selector.wakeup(). This eventually causes the Acceptor thread to exit its loop, and finally call acceptorDone(), which is responsible for closing the server channel. This means that FD_SOCK.stop() can complete before its server channel is closed. Presumably, this affects other protocols that use NioServer.

If a channel containing FD_SOCK2 configured with port_range=1 (or any protocol that uses NioServer) is disconnected and reconnected in quick succession, FD_SOCK2 will expect to be able reestablish the server channel on the same port. However, since the server channel may not yet be closed, the open socket can cause the channel to fail to reconnect.

OT: Why do the semantics for FD_SOCK2.port_range differ from all other protocols? For most other protocols, port_range=0 means do not retry other ports. But for FD_SOCK2, port_range=1 does this (port_range=0 is invalid).