This content has been marked as final.
Show 4 replies
-
1. Re: MessagingBuffer implementation leaking into MessageImpl
timfox Jun 18, 2008 8:49 AM (in response to ataylor)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. -
2. Re: MessagingBuffer implementation leaking into MessageImpl
ataylor Jun 18, 2008 9:00 AM (in response to 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? -
3. Re: MessagingBuffer implementation leaking into MessageImpl
timfox Jun 18, 2008 9:02 AM (in response to ataylor)If you add a factory method to create the actual buffer so the message doesn't know or care what actual type its creating.
-
4. Re: MessagingBuffer implementation leaking into MessageImpl
timfox Jul 4, 2008 7:44 AM (in response to ataylor)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.