I have done these following changes, as part of of MessagingBuffer refactoring, per https://jira.jboss.org/jira/browse/JBMESSAGING-1394
I have stripped down org.jboss.netty.buffer a bit, for what we needed.
I'm basically providing three types of buffers that exist on the original netty.buffer:
- HeapChannelBuffer - Which is a byte backed Buffer
- DynamicChannelBuffer - Which is using HeapChannelBuffer, and auto-extending it
- ByteBufferBackedChannelBuffer - Which will have a ByteBuffer inside.
All these classes are implementing ChannelBuffer and MessagingBuffer.
For creating a new buffer, you should use the methods provided by ChannelBuffers:
buffer(int capacity) - This method will create a fixed size MessagingBuffer
dynamicBuffer(final int estimatedLength) - This method will create a SelfExpandable MessagingBuffer
dynamicBuffer(final byte initialBuffer) - This method will create a SelfExpandable MessagingBuffer, but reusing the initialBuffer. Be careful though, the reference will be directly used on the createdBuffer. If your buffer will be used by other operations, you should instead create a new buffer and perform a write.
buffer(final int capacity) - This method will create a fixed size MessagingBuffer
wrappedBuffer(final byte array) - It will create a Buffer, with writePosition at the end, and readPosition at 0
wrappedBuffer(final ByteBuffer buffer) - It will wrap a Bytebuffer on a MessagingBuffer. The position on this buffer won't affect the position on the inner buffer
We are now using dynamicBuffers on the MessageBody.
And in a few places, where we are reading the body, we are wrapping a byte on a dynamicBuffer, avoiding this way an extra copy.
Also, there is one difference on the old ByteBufferWrapper, and the "new" ByteBufferBackedChannelBuffer.
ByteBufferWrapper would aways refer to the positioning inside the ByteBuffer, while the new one will have an independent positioning, and because of that I had to make a few changes on Journal and Paging, as we used ByteBufferWrapper since we need to play with ByteBuffer because NIO and AIO SequentialFiles.
I'm writing some of this information on the package.html, and I should commit shortly as soon as I finish some latest tests.