Rule for multiplicity of channels to remote hosts.

[Leandro Cruz]

Ah... Sorry... My advice/example is for client side only.

Netty already schedules a thread for you to read from the channel. The point
is not to have one-thread-per-client-old-io-approach. Maybe you can
distribute your load to a thread pool, where some threads manage a number o
clients. Could you give me one example of what/how your client and server
communicate?


--
Leandro Rodrigo Saad Cruz


On Fri, Apr 16, 2010 at 7:19 PM, Will S. <willyjstevens at hotmail.com> wrote:

>
> Hi Leandro,
>
> Thank you kindly for the reply.  That was one thought I had to was to use
> some type of blocking queue which a separate thread for each channel would
> take() when a new message arrived.
>
> But I'm trying to weigh (the value returned, especially) of how many
> threads
> are needed to service 1 client. Right now, it's like for one channel I
> have:
>  - 1 thread to take the message off that queue and write
>  - 1 thread in my application layer putting the message on the queue
>  - Then x worker threads for 1 client channel in the Executor, which is
> passed into the NioClientSocketChannelFactory constructor.
>  - Then x boss threads in the Executor also passed into the constructor.
>
> So unless my math is wrong, that is >= 4 threads per client!!  Yikes.
>
> Now, in reality my plan is to share the same physical worker thread
> Executor
> and maybe the boss Executor too.
>
> Anyway, just trying to hammer all these details out before designing.
>
> Thanks again!
> --
> View this message in context:
> http://n2.nabble.com/Rule-for-multiplicity-of-channels-to-remote-hosts-tp4914969p4915451.html
> Sent from the Netty User Group mailing list archive at Nabble.com.
> _______________________________________________
> netty-users mailing list
> netty-users at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/netty-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/netty-users/attachments/20100416/77526409/attachment-0001.html