Scattering/GatheringByteChannel and Netty

["이희승 (Trustin Lee)"]

Hi Aaron,

On 07/11/2009 03:25 PM, Aaron Whiteside wrote:
> Hi, I'm a new user to Netty and I have a question..
> 
> Does Netty support the NIO scattering/gathering byte channels at a high
> level? What would be really nice to have is the ability to somehow combine a
> FrameDecoder and a ChannelBufferFactory so that one could use a heap based
> buffer for ones protocol headers and a direct buffer for the protocols data
> payload.
> 
> The reasoning behind such an idea is that I am not interested in parsing the
> data payload in my application, all I want to do is persist it to disk or
> write it off to another connection. And using direct buffers for this means
> I get the most efficiency possible. But with the protocol headers I do want
> to parse those and I would prefer not to incur the overhead of
> reading/writing a direct buffer from the java space, since heap based
> buffers are much more efficient in this case.

Current Sun JDK doesn't manage direct buffer memory usage efficiently
enough, and Netty uses a heap buffer as its primary buffer type.
Especially, if scattered write is performed with the mixture of heap and
direct buffers, it's an expressway to OOME.  Once this issue goes away,
I'd consider to change the default buffer type.

To reduce the number of memory copy operations, Netty provides composite
buffers.  You can create a composite buffer from more than one buffer by
calling ChannelBuffers.wrappedBuffer(...).  Right before writing the
buffer to the write, Netty merges the buffers into a bigger one.  Until
then, there's no memory copy.

> On an ending note I must say I am thoroughly impressed with Netty it has a
> clean and beautiful API the likes of which i haven't seen in years, if at
> all.

Thank you!  You made my day.  Let me know if you are interested in
writing some testimonial which could be published to the Netty web site.
;)  At least I'd like to quote your sentence here.

Cheers,
Trustin