Rule for multiplicity of channels to remote hosts.

[Johnny Luong]

Will S. 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!

I think it's just a flexibility matter in your design, but here are some 
thoughts:

Well, if all your doing from your application layer is putting the 
message onto another queue, then you could use the IO thread to perform 
this action.

As far as the worker / boss threads are concerned, you could just use an 
OioClientSocketChannelFactory, then thats another thread gone.

Unless your threads are completely busy, its likely that the threads in 
use will grow in proportion to how busy your application is and hence 
the ratio of clients to threads should actually be pretty high.

At least for the application I'm writing, it seems to work out that way. :)

Best,
Johnny