Rule for multiplicity of channels to remote hosts.

[Will S.]

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!!
-- 
View this message in context: http://n2.nabble.com/Rule-for-multiplicity-of-channels-to-remote-hosts-tp4914969p4928699.html
Sent from the Netty User Group mailing list archive at Nabble.com.