MessagingBuffer implementation leaking into MessageImpl

[ataylor]

Currently when a message is encoded or decoded, the methods are called from The transport layer and the MessagingBuffer implementation is specific to this transport. The transport will encode/decode the messages by using the MessagingCodecImpl and this in turn delegates down to a specific Packet depending on the PacketType. When a Packet encodes/decodes itself it should not need to know anything about the MessagingBuffer implementation.

However I've noticed that in MessageImpl the body of the message is also a MessagingBuffer and in the constructor and the decode method we default to the Mina Implementation. This all works at present since we only use Mina but will fail when the ByteBufferWrapper or the new Netty implementation when Trustin adds it.

the method clearBody() in JbossBytesMessage and JBossStreamMessage also assumes an implementation.

1 solution would be to add a new class 'MessageBody' that uses an underlying ByteBuffer and when the message is encoded/decoded we call buffer.put(byteBuffer) etc.

I'm not 100% sure what the effect on performance will be but i was thinking that using a direct ByteBuffer will mean no copying is done.

thoughts?

[timfox]

The reason the message holds the buffer directly is to minimise copying. If we stored it as a byte buffer then copied it to the mina buffer that would involve unnecessary copying.

For this reason, I abstracted out the MessagingBuffer interface so it does not depend on MINA.

[ataylor]

For this reason, I abstracted out the MessagingBuffer interface so it does not depend on MINA.

The problem is that if i create a new Message it makes an assumption that we are using Mina and defaults he body to an IoBufferWrapper. If we were using the INVM transport properly and de/serialising to a ByteBufferWrapper instead when we encode or decode the message all the headers get written to the ByteBufferImpl and the bod gets written to the defaulted IoBufferWrapper.

Also when we write the buffer we call buff.array(), isntthat doing a copy anyway?

[timfox]

If you add a factory method to create the actual buffer so the message doesn't know or care what actual type its creating.

[timfox]

I deleted the MessagingBufferFactory and instead added a createBuffer method on remoting connection and connector. It's really the connector that knows about how to create the buffer, the MessagingFactoryImpl class was in utils and had knowledge of MINA specifics which should only happen in the MINA sub dirs.