Update on 6July06:It turns out the root cause of the problem is related to my Decoder implementation. More details can be found in the JIRA Issue.

The lesson is: Don't use Mina 0.8.2. Go for Mina 0.9.4+ or else risk data corruption.

Update on 4July06: JIRA Issue submitted to the Mina group.

Just found a nasty race condition in using

org.apache.mina.util.Queue

in Mina 0.8.2.

When invoked from IOAdapter$SessionHandlerAdapter.dowrite(), the Queue.isEmpty() is not properly synchronized. This causes data corruption when the network IO is under high load! I was hit by it when I changed my log4j configuration to use pure asyn appenders.

The good news is it's easy to patch. I simply took the gut out of the original Mina's queue implementation, and replaced it with a simple delegation to

java.util.concurrent.ConcurrentLinkedQueue

There are some features lost such as the removal of the List interface (from the Mina's Queue class). But in this case the additional List interface methods are not actually used anywhere else in Mina 0.8.2!

IMHO, Mina should really take advantage of JKD5 features such as non-blocking synchronization , instead of having synchronized statements/blocks all over the places. After all, isn't Mina all about performance ?

(Will try to post the patch back to the Mina group when I got a chance.)