When sending a unicast message to self (dest == local address), unless it's DONT_LOOPBACK, we can simply loop it back up on the same thread. This means, we're not assigning it a sequence number, and forfeit retransmission (it is delivered on the same thread, so no need to retransmit).

There is no defined ordering though, but the same holds e.g. for 100 threads sending messages: the order of the threads getting seqnos assigned is random (first-come-first-served).

Some protocols (e.g. merging) fail, so we need to investigate this.

Question: why not loop back higher up the stack, e.g. in the JChannel directly?

Whatever the solution is, this needs to be enabled by an attribute (loopback?). The default should be false.