Even further, I think we can reuse DataInput and DataOutput interface instead of MessagingBuffer. The reasoning behind this is that putInt() is the only random access method in MessagingBuffer and it's only used for writing the length field during encoding. Except that, every access is sequential. What the current decoder implementation does is to read the length field first and wait until the whole message is received, which means the whole message is read into memory. Therefore, using a stream to read a message will never block once a message is properly split (or assembled) in the networking layer (MINA or Netty level). Writing a message is a different matter because we need to fill the length field. We could fill the length field in the networking layer (MINA or Netty level) to work around this issue. The disadvantage of this approach is that each networking layer implementation should know how one or more packets are split or assembled into a message. It means both MINA-based transport and Netty-based transport should know where the length field of a message is located. It's a little bit of code duplication, but I don't think this will change once implemented because their change means the protocol incompatibility. read and write methods for SimpleString could be provided as static utility methods or member methods of SimpleString. WDYT? View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4161749#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...