In ClientConnectionOpenListener, we have 2 places where, in I-O thread the connection is asked to send a buffer (in a Task thread) then the reads are resumed (in the I-O thread).
So at the selector level we have 2 setOps done in // that could interfere with each other (one of the 2 interested op could be lost).
Same in ServerConnectionOpenListener, we 1 place when starting TLS.

A possible fix would be to simply resumeReads first in the I-O thread, then call connection.send This is what is done in all other cases. These 3 occurrences seem a left over.