Wouldn't it make sense to multiplex a Selector across multiple channels in order to efficiently manage threads since you can have multiple channels being monitored by one selector. You could have 10 channels, 1 selector in the main thread and 1 I/O thread. Currently, 10 channels would mean 10 selectors each in their own thread.
-- ..Cheers Mark On 9/20/07, Trustin Lee <[EMAIL PROTECTED]> wrote: > > On 9/21/07, Gary Helmling <[EMAIL PROTECTED]> wrote: > > > > > > Mark Webb wrote: > > > > > > I am interested in having one IoAcceptor listen on multiple > ports. This > > > acceptor will have one Selector and based on the incoming > connection/data, > > > the proper handler will be triggered. > > > > This would be pretty useful for me as well. I have a server that will > be > > handling essentially the same data over 2 different protocols on 2 > different > > ports. For each protocol the handling would be slightly different, so a > > separate IoHandlerAdapter on each port would be useful. > > > > This capability seemed to be present in the 1.1.x releases with the: > > SocketAcceptor.bind(SocketAddress, IoHandler, IoServiceConfig) > > > > method (don't know if it worked the way I expected with multiple calls). > > Was this causing problems that were fixed with the current restructuring > in > > the trunk? > > Yes, we redesigned the API for more simplicity. IIRC, we didn't like > the way how threads are managed in MINA (e.g. assumption that one > SocketAcceptor means one acceptor thread). In 2.0, we will introduce > much more efficient thread management built-in, as Mike mentioned > already. No matter how many acceptor or connector instances are > created, the number of I/O threads will be maintained in an optimal > number. > > HTH, > Trustin > -- > what we call human nature is actually human habit > -- > http://gleamynode.net/ > -- > PGP Key ID: 0x0255ECA6 >
