Rule for multiplicity of channels to remote hosts.

["Trustin Lee (이희승)"]

Hello Will et al,

Thanks for a great discussion.  I'd love to listen to your feed back!

Trustin

Will S. wrote:
> Hi Johnny, thank you for the reply.
> 
> After doing a bit of digging, I found that I can forget about maintaining my
> own queue.  Since I'm using the 'standard' NIO socket channel
> implementation, the NioSocketChannel class already maintains its own write
> queue internally (see instance variable "writeBuffer".)  Therefore I can
> just fire as many writes as I want at it, as long as I track what I'm doing
> with registering my completion listener off the future object.  
> 
> I am beginning to appreciate that *everything* in Netty is an asynchronous
> operation which yields a ChannelFuture to do whatever you want with - your
> choice.
> 
> Now regarding the threads, I think I am leaning towards the
> OrderedMemoryAwareThreadPoolExecutor implementation as I desire the ordered
> characteristic and being proactive in mitigating memory issues by setting
> limits. 
> 
> I don't mean to be careless but I'm trying to take my hands off the wheel a
> little and let Netty do it's thing by handling all the real work -> so I
> supply it my Executor and my ChannelHandlers and let it do the rest. I'll
> let you know how it goes in 3 months! (good or bad)
> 
> BTW, I am going to investigate that OrderedMemoryAwareThreadPoolExecutor to
> see how it operates. Thanks!!

-- 
what we call human nature in actuality is human habit
http://gleamynode.net/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.jboss.org/pipermail/netty-users/attachments/20100428/4e5516fe/attachment-0001.bin