You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Mark <el...@gmail.com> on 2007/09/19 16:55:01 UTC
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
Posted by Mike Heath <mh...@apache.org>.
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.
Re: multiple handlers per IoService
Posted by jian wu <he...@gmail.com>.
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 <gh...@gmail.com> 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.
>
>
Re: multiple handlers per IoService
Posted by Mark <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
>
> On 9/21/07, Gary Helmling <gh...@gmail.com> 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
Posted by Mark <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
>
> On 9/25/07, Mark <el...@gmail.com> 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
Posted by Mark <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
>
> No, not yet. It's must to have in 2.0 though. :)
>
> Cheers,
> Trustin
>
> On 9/25/07, Mark <el...@gmail.com> 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 <tr...@gmail.com> wrote:
> > >
> > > On 9/25/07, Mark <el...@gmail.com> 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
Posted by Trustin Lee <tr...@gmail.com>.
No, not yet. It's must to have in 2.0 though. :)
Cheers,
Trustin
On 9/25/07, Mark <el...@gmail.com> 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 <tr...@gmail.com> wrote:
> >
> > On 9/25/07, Mark <el...@gmail.com> 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
Posted by Mark <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
>
> On 9/25/07, Mark <el...@gmail.com> 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
Posted by Trustin Lee <tr...@gmail.com>.
On 9/25/07, Mark <el...@gmail.com> 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
Posted by Mark <el...@gmail.com>.
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 <tr...@gmail.com> wrote:
>
> On 9/21/07, Gary Helmling <gh...@gmail.com> 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
Posted by Trustin Lee <tr...@gmail.com>.
On 9/21/07, Gary Helmling <gh...@gmail.com> 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
Posted by Gary Helmling <gh...@gmail.com>.
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.
Re: multiple handlers per IoService
Posted by Mark <el...@gmail.com>.
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.
--
..Cheers
Mark
On 9/19/07, Mark <el...@gmail.com> wrote:
>
> 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