Re: multiple handlers per IoService
Trustin, Shall I open entries in JIRA for a Selector Pool class and a Service worker pool class? Sounds like you are more in tune with what you want to do. I think it would make more sense for you to add in the entry(s). Thanks, Mark On 9/25/07, Trustin Lee [EMAIL PROTECTED] wrote: No, not yet. It's must to have in 2.0 though. :) Cheers, Trustin On 9/25/07, Mark [EMAIL PROTECTED] wrote: As long as the size of the pool could = 1. Has any work been done on this? Thanks Trustin. -- ..Cheers Mark On 9/25/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/25/07, Mark [EMAIL PROTECTED] wrote: 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. Yes, that's what I am saying. By managing a global pool of selectors and I/O processors, we could optimize thread usage. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- ..Cheers Mark
Re: multiple handlers per IoService
A Selector pool something like: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/tomcat/util/net/NioSelectorPool.java On 9/25/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/25/07, Mark [EMAIL PROTECTED] wrote: 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. Yes, that's what I am saying. By managing a global pool of selectors and I/O processors, we could optimize thread usage. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- ..Cheers Mark
Re: multiple handlers per IoService
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
Re: multiple handlers per IoService
As long as the size of the pool could = 1. Has any work been done on this? Thanks Trustin. -- ..Cheers Mark On 9/25/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/25/07, Mark [EMAIL PROTECTED] wrote: 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. Yes, that's what I am saying. By managing a global pool of selectors and I/O processors, we could optimize thread usage. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: multiple handlers per IoService
No, not yet. It's must to have in 2.0 though. :) Cheers, Trustin On 9/25/07, Mark [EMAIL PROTECTED] wrote: As long as the size of the pool could = 1. Has any work been done on this? Thanks Trustin. -- ..Cheers Mark On 9/25/07, Trustin Lee [EMAIL PROTECTED] wrote: On 9/25/07, Mark [EMAIL PROTECTED] wrote: 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. Yes, that's what I am saying. By managing a global pool of selectors and I/O processors, we could optimize thread usage. Cheers, Trustin -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6 -- what we call human nature is actually human habit -- http://gleamynode.net/ -- PGP Key ID: 0x0255ECA6
Re: multiple handlers per IoService
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
Re: multiple handlers per IoService
Trustin, Where can I find more information regarding this sentance: No matter how many acceptor or connector instances are created, the number of I/O threads will be maintained in an optimal number. So if I create 2 SocketAcceptor instances each with different IoHandlers, how can I/MINA optimaly manage the number of Threads created? -- ..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
Re: multiple handlers per IoService
Hi, You might want to look into org.apache.mina.handler.chain.IoHandlerChain, if each IoHandler will handle one type of message/protocol and there is no overlap among different IoHandlers, you probably can simply build a IoHandlerChain to handle all the protocols, this might not be an optimal solution, but it is not difficult to implement. My two cents, Jian On 9/20/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? Thanks, Gary -- View this message in context: http://www.nabble.com/multiple-handlers-per-IoService-tf4481513s16868.html#a12799299 Sent from the Apache MINA Support Forum mailing list archive at Nabble.com.
multiple handlers per IoService
Can this be done with MINA now? I would like to put together a framework that will have one Acceptor and register multiple IoHandlerApapters each processing different types of data. -- ..Cheers Mark
Re: multiple handlers per IoService
It would also be nice if we had some way of sharing thread pools and selectors between Acceptors and Connectors. It would take quite a bit of refactoring but it may be nice feature to have for those of us building proxies that have multiple acceptors and multiple connectors working in conjunction. -Mike Mark wrote: Just to clarify this further, because I don't think I described what I wanted to properly. 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. So for each port, you will have an associated handler but this will all go through a common Selector. The goal here is to keep the number of threads at a minimum. I am building a system that may be listening on many different ports and each port will get different types of data. The number of ports could be over 20. Taking a quick look at the current SocketAcceptor, this would be alot of work.
