You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@mina.apache.org by gonzalo diethelm <gd...@dcv.cl> on 2009/06/09 23:04:08 UTC
MINA and threads
Although not strictly necessary, I would have the expectation that,
since MINA is based on NIO, it should be possible to build a single
executable that listens on a port and connects to itself on that port,
all from a single thread. Is this possible at all?
I ask because I have been toying with the Reverser example and there are
a few things I don't quite understand. I have modified the
log4j.properties file to have the thread name printed (using a
ConversionPattern with value "%t %p[%c{1}] %m%n") and added some logging
to the server under the following conditions:
* Start up and accept connections on port 8888.
* Wait for a message with the text "shutdown".
* Shut server down.
The shutdown process is implemented with a listener on a CloseFuture on
the session, as discussed on this list a few days ago. Next you will
find a short log for an example where the client is a telnet session to
port 8888; the first word on each line is the thread name:
main INFO[Main] => Starting up
main INFO[Main] => Acceptor created
main INFO[Main] => Acceptor configured handler
main INFO[Main] => Acceptor bound
main INFO[Main] => Node listening on port 8888
main INFO[Main] => Finished
NioProcessor-1 INFO[ReverseProtocolHandler] => Session created
NioProcessor-1 INFO[ReverseProtocolHandler] => Session opened
NioProcessor-1 INFO[ReverseProtocolHandler] => Session received:
[shutdown]
NioProcessor-1 INFO[ReverseProtocolHandler] => Session creating
closeFuture
NioProcessor-1 INFO[ReverseProtocolHandler] => Session adding listener
to closeFuture
NioProcessor-1 INFO[ReverseProtocolHandler] => Session waiting for
closeFuture
NioProcessor-1 INFO[ReverseProtocolHandler] => Session caught an
exception
NioProcessor-1 INFO[ReverseProtocolHandler] => Session done closing,
will now shutdown
NioProcessor-1 INFO[Main] => Node shutting down
NioProcessor-1 INFO[Main] => Acceptor unbound
NioProcessor-1 INFO[Main] => Acceptor disposed
NioProcessor-1 INFO[ReverseProtocolHandler] => Session closed
Now, it is obvious from this log that there are at least two threads at
play here: a main thread that ends up right away and a secondary thread
NioProcessor-1 where all the session management happens. Why is this so?
Is it because the main thread simply falls off the end of the earth?
Just as a reminder, this is the code for the main routine:
public static void main(String[] args) throws Exception {
LOGGER.info("=> Starting up");
acceptor = new NioSocketAcceptor();
LOGGER.info("=> Acceptor created");
// Prepare the configuration
DefaultIoFilterChainBuilder chain = acceptor.getFilterChain();
chain.addLast("codec",
new ProtocolCodecFilter(
new
TextLineCodecFactory(Charset.forName("UTF-8"))));
acceptor.setHandler(new ReverseProtocolHandler());
LOGGER.info("=> Acceptor configured handler");
acceptor.bind(new InetSocketAddress(PORT));
LOGGER.info("=> Acceptor bound");
LOGGER.info("=> Node listening on port " + PORT);
LOGGER.info("=> Finished");
}
Should there be an instruction after the acceptor.bind() call that
somehow waits until the acceptor is done? Perhaps Reverser this is not
the best example to be looking at?
Thanks for any light shed on my ignorance. Best regards,
--
Gonzalo Diethelm
DCV - Chile
RE: MINA and threads
Posted by gonzalo diethelm <gd...@dcv.cl>.
> From: Christopher Popp [mailto:christopherpopp@yahoo.com]
> Sent: Wednesday 10 Jun 2009 11:22
> To: users@mina.apache.org
> Subject: Re: MINA and threads
>
> I think you might be confusing the thread model a bit...with MINA you
> don't need a thread per client. There is one thread listening which
> handles accepting connections. There are then a configurable pool of
I/O
> handling threads (defaulting to # of cores +1) which handle incoming
> messages. Optionally, you can specify an ExecutorFilter in your
filter
> chain if you want another pool of threads available later in case you
> expect this would benefit your application logic.
Ok, thanks for the clarification Christopher.
> So...at a minimum, you could configure MINA to only use two threads
(one
> for accepting, and one for processing I/O), and have that handle any
> number of connected clients.
Then it is clear I was not understanding MINA's architecture. Thanks
again for laying it down for me.
> Chris Popp
--
Gonzalo Diethelm
DCV - Chile
Re: MINA and threads
Posted by Emmanuel Lecharny <el...@apache.org>.
Christopher Popp wrote:
> I think you might be confusing the thread model a bit...with MINA you don't need a thread per client. There is one thread listening which handles accepting connections. There are then a configurable pool of I/O handling threads (defaulting to # of cores +1) which handle incoming messages. Optionally, you can specify an ExecutorFilter in your filter chain if you want another pool of threads available later in case you expect this would benefit your application logic.
>
> So...at a minimum, you could configure MINA to only use two threads (one for accepting, and one for processing I/O), and have that handle any number of connected clients.
>
I would say three : main, the IoAcceptor thread and a IoProcessor
thread. Not a big difference though :)
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
Re: MINA and threads
Posted by Christopher Popp <ch...@yahoo.com>.
I think you might be confusing the thread model a bit...with MINA you don't need a thread per client. There is one thread listening which handles accepting connections. There are then a configurable pool of I/O handling threads (defaulting to # of cores +1) which handle incoming messages. Optionally, you can specify an ExecutorFilter in your filter chain if you want another pool of threads available later in case you expect this would benefit your application logic.
So...at a minimum, you could configure MINA to only use two threads (one for accepting, and one for processing I/O), and have that handle any number of connected clients.
Chris Popp
________________________________
From: gonzalo diethelm <gd...@dcv.cl>
To: users@mina.apache.org
Sent: Wednesday, June 10, 2009 10:08:57 AM
Subject: RE: MINA and threads
> feel free to ask more!
I have, thanks for the offer.
> Basically, MINA was designed as a SEDA based framework (even if this
> target has been lost in the meantime, somehow ...). Since then, it has
> evolved a bit.
My recollection of SEDA is that it had a single thread managing all socket IO (implemented with Java NIO or a C library called via JNI) and all file IO (since there is no consistent way of achieving good asynch file IO across OSs, this is _simulated_ with a thread pool, but this is an _implementation detail_). The only "real" (in the sense that it is not an implementation detail) thread pool that I recall in SEDA is the pool that fetches incoming messages in batches and processes them. I could be wrong; this is all from memory.
> The internal design was done in order to decouple the concerns as much
> as possible. So you have a thread handling incoming connections, N
> processor, each of them having a selector, to process the incoming and
> outgoing events (read and write) each processor being associated with a
> thread, and as you can add an Executor filter in the chain, you can also
> have N threads to handle the load (this construction is the only
> remaining SEDA flavor in the framework).
But then the question arises: why do you even need NIO to do this? If every accept, connect, read and write are run from separate threads, you could just issue blocking calls. Or am I not understanding your description?
> All those threads are intended to offer a better scalability, but that
> has still to be proven :)
One of the canonical problems that SEDA was trying to solve was the "C10K" problem: having a web server capable of handling ten thousand clients simultaneously (see http://www.kegel.com/c10k.html). My recollection is that using threads for each of those clients is out of the question, in that it is not possible to have that many threads operating reliably.
> But more than that, and many persons are questioning the scalability,
> it's a damn simple framework when it comes to quickly design a server,
> letting you to focus on what matters : the codec and the handler.
>
> At some point in the future, though, considering other aspects than ease
> of use, we may have to tune the design to allow one user to select the
> best solution. We are far from this point ... :/
Understood.
> I hope I brought a bit of light in the dark :)
You have, and you have also brought up new questions... Thus science progresses...
> cordialement, regards,
> Emmanuel Lécharny
--
Gonzalo Diethelm
DCV - Chile
-----------------------------------------
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena.
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje.
"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law.
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.
RE: MINA and threads
Posted by gonzalo diethelm <gd...@dcv.cl>.
> feel free to ask more!
I have, thanks for the offer.
> Basically, MINA was designed as a SEDA based framework (even if this
> target has been lost in the meantime, somehow ...). Since then, it has
> evolved a bit.
My recollection of SEDA is that it had a single thread managing all socket IO (implemented with Java NIO or a C library called via JNI) and all file IO (since there is no consistent way of achieving good asynch file IO across OSs, this is _simulated_ with a thread pool, but this is an _implementation detail_). The only "real" (in the sense that it is not an implementation detail) thread pool that I recall in SEDA is the pool that fetches incoming messages in batches and processes them. I could be wrong; this is all from memory.
> The internal design was done in order to decouple the concerns as much
> as possible. So you have a thread handling incoming connections, N
> processor, each of them having a selector, to process the incoming and
> outgoing events (read and write) each processor being associated with a
> thread, and as you can add an Executor filter in the chain, you can also
> have N threads to handle the load (this construction is the only
> remaining SEDA flavor in the framework).
But then the question arises: why do you even need NIO to do this? If every accept, connect, read and write are run from separate threads, you could just issue blocking calls. Or am I not understanding your description?
> All those threads are intended to offer a better scalability, but that
> has still to be proven :)
One of the canonical problems that SEDA was trying to solve was the "C10K" problem: having a web server capable of handling ten thousand clients simultaneously (see http://www.kegel.com/c10k.html). My recollection is that using threads for each of those clients is out of the question, in that it is not possible to have that many threads operating reliably.
> But more than that, and many persons are questioning the scalability,
> it's a damn simple framework when it comes to quickly design a server,
> letting you to focus on what matters : the codec and the handler.
>
> At some point in the future, though, considering other aspects than ease
> of use, we may have to tune the design to allow one user to select the
> best solution. We are far from this point ... :/
Understood.
> I hope I brought a bit of light in the dark :)
You have, and you have also brought up new questions... Thus science progresses...
> cordialement, regards,
> Emmanuel Lécharny
--
Gonzalo Diethelm
DCV - Chile
-----------------------------------------
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena.
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje.
"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law.
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.
Re: MINA and threads
Posted by Emmanuel Lecharny <el...@apache.org>.
gonzalo diethelm wrote:
>> Implementing everything with a single thread means that we use one
>> selector to handle the accept and the session. possible, but then, why
>> using MINA ? You can do that with a simple SocketServer, a selector and
>> a few glue around it.
>>
>> The idea with MINA was to create a scalable NIO framework, easy enough
>> to use. Doing that on a single thread would kill the initial design...
>>
> ...
>
>> Well, it's impossible to design a system which fits all the needs. Also
>> I don't really see the problem you are trying to fix with this 'one
>> thread to manage everything'. You are the first person on the mailing
>> list in 3 years to expose such a need. Do you have some technical
>> constraints that limit you to using only one thread ?
>>
>
> More than a need, I am trying to grasp the design objectives for MINA. I come from a C++ experience, where sometimes you will want to choose to have everything running in one single thread, doing all the multiplexing yourself, and sometimes you will want to use threads, maybe associating one thread with one connection, or pooling your threads because their creation and destruction can be expensive.
>
Basically, MINA was designed as a SEDA based framework (even if this
target has been lost in the meantime, somehow ...). Sicne then, it has
aevolved a bit.
The internal design was done in otder to decouple the concerns as much
as possible. So you have a thread handling incoming connections, N
processor, each of them having a selector, to process the incoming and
outgoing events (read and write) each processor being associated with a
thread, and as you can add an Executor filter in the chain, you can also
have N threads to handle the load (this construction is the only
remaining SEDA flavor in the framework).
All those threads are intended to offer a better scalability, but that
has still to be proven :)
But more than that, and many persons are questioning the scalability,
it's a damn simple framework when it comes to quickly design a server,
letting you to focus on what matters : the codec and the handler.
At some point in the future, though, considering other aspects than ease
of use, we may have to tune the design to allow one user to select the
best solution. We are far from this point ... :/
> I have used the C++ ACE framework in the past, and it does give the designer the choice regarding which threading model to follow. Mind you, I am NOT saying that ACE is better than MINA, or that C++ is better than Java. I WANT to use MINA; I also would like to learn the extent of my choices / constraints set by the framework, and the reasons why it provides those choices /constraints, and not others.
>
I hope I brought a bit of light in the dark :)
fell free to ask more !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: MINA and threads
Posted by gonzalo diethelm <gd...@dcv.cl>.
> Implementing everything with a single thread means that we use one
> selector to handle the accept and the session. possible, but then, why
> using MINA ? You can do that with a simple SocketServer, a selector and
> a few glue around it.
>
> The idea with MINA was to create a scalable NIO framework, easy enough
> to use. Doing that on a single thread would kill the initial design...
...
> Well, it's impossible to design a system which fits all the needs. Also
> I don't really see the problem you are trying to fix with this 'one
> thread to manage everything'. You are the first person on the mailing
> list in 3 years to expose such a need. Do you have some technical
> constraints that limit you to using only one thread ?
More than a need, I am trying to grasp the design objectives for MINA. I come from a C++ experience, where sometimes you will want to choose to have everything running in one single thread, doing all the multiplexing yourself, and sometimes you will want to use threads, maybe associating one thread with one connection, or pooling your threads because their creation and destruction can be expensive.
I have used the C++ ACE framework in the past, and it does give the designer the choice regarding which threading model to follow. Mind you, I am NOT saying that ACE is better than MINA, or that C++ is better than Java. I WANT to use MINA; I also would like to learn the extent of my choices / constraints set by the framework, and the reasons why it provides those choices /constraints, and not others.
> cordialement, regards,
> Emmanuel Lécharny
Merci bien,
--
Gonzalo Diethelm
DCV - Chile
-----------------------------------------
Declaración de confidencialidad: Este Mensaje esta destinado para
el uso de la o las personas o entidades a quien ha sido dirigido y
puede contener información reservada y confidencial que no puede
ser divulgada, difundida, ni aprovechada en forma alguna. El uso no
autorizado de la información contenida en este correo podrá ser
sancionado de conformidad con la ley chilena.
Si usted ha recibido este correo electrónico por error, le pedimos
eliminarlo junto con los archivos adjuntos y avisar inmediatamente
al remitente, respondiendo este mensaje.
"Before printing this e-mail think if is really necesary".
Disclosure: This Message is to be used by the individual,
individuals or entities that it is addressed to and may include
private and confidential information that may not be disclosed,
made public nor used in any way at all. Unauthorized use of the
information in this electronic mail message may be subject to the
penalties set forth by Chilean law.
If you have received this electronic mail message in error, we ask
you to destroy the message and its attached file(s) and to
immediately notify the sender by answering this message.
Re: MINA and threads
Posted by Emmanuel Lecharny <el...@apache.org>.
gonzalo diethelm wrote:
>>> Although not strictly necessary, I would have the expectation that,
>>> since MINA is based on NIO, it should be possible to build a single
>>> executable that listens on a port and connects to itself on that
>>>
> port,
>
>>> all from a single thread. Is this possible at all?
>>>
>> No. As soon as you create an Acceptor, it spawns a new thread. Then as
>> soon as you accept an incoming connection, at least one new thread is
>> created to process the connection.
>>
>> What you see in the logs is just plain normal The Main thread may end,
>> but as you have at least one more existing thread.
>>
>
> Is this common practice in the Java NIO world? Because on the C/C++
> side, there are good reasons why one would avoid using threads at all
> and move toward a non-blocking approach, even if it is more difficult to
> implement. Admittedly, using threads in Java may be more of a
> non-brainer; I admit that I can't help but feel a little disappointed
> that it is not possible to do all of this in MINA on a single thread (if
> one so wanted). Again, maybe I am too influenced by my previous C++
> experience.
>
Implementing everything with a single thread means that we use one
selector to handle the accept and the session. possible, but then, why
using MINA ? You can do that with a simple SocketServer, a selector and
a few glue around it.
The idea with MINA was to create a scalable NIO framework, easy enough
to use. Doing that on a single thread would kill the initial design...
> Let me ask this in another way: could I build the mentioned example
> (single executable that listens on a port and connects to itself on that
> port, all from a single thread) by programming directly to Java NIO,
> totally bypassing MINA?
>
I guess so.
> If the answer to the above is yes, then it would seem that MINA forces
> the choice of a concurrency / processing model (one thread per
> connection). Keep in mind that there is a whole gamut of choices here,
> ranging from "single thread, non-blocking" to "thread per connection,
> blocking" at the extremes, including the "thread-pool, blocking or
> non-blocking" right in the middle.
>
Well, it's impossible to design a system which fits all the needs. Also
I don't really see the problem you are trying to fix with this 'one
thread to manage everything'. You are the first person on the mailing
list in 3 years to expose such a need. Do you have some technical
constraints that limit you to using only one thread ?
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
RE: MINA and threads
Posted by gonzalo diethelm <gd...@dcv.cl>.
> > Although not strictly necessary, I would have the expectation that,
> > since MINA is based on NIO, it should be possible to build a single
> > executable that listens on a port and connects to itself on that
port,
> > all from a single thread. Is this possible at all?
>
> No. As soon as you create an Acceptor, it spawns a new thread. Then as
> soon as you accept an incoming connection, at least one new thread is
> created to process the connection.
>
> What you see in the logs is just plain normal The Main thread may end,
> but as you have at least one more existing thread.
Is this common practice in the Java NIO world? Because on the C/C++
side, there are good reasons why one would avoid using threads at all
and move toward a non-blocking approach, even if it is more difficult to
implement. Admittedly, using threads in Java may be more of a
non-brainer; I admit that I can't help but feel a little disappointed
that it is not possible to do all of this in MINA on a single thread (if
one so wanted). Again, maybe I am too influenced by my previous C++
experience.
Let me ask this in another way: could I build the mentioned example
(single executable that listens on a port and connects to itself on that
port, all from a single thread) by programming directly to Java NIO,
totally bypassing MINA?
If the answer to the above is yes, then it would seem that MINA forces
the choice of a concurrency / processing model (one thread per
connection). Keep in mind that there is a whole gamut of choices here,
ranging from "single thread, non-blocking" to "thread per connection,
blocking" at the extremes, including the "thread-pool, blocking or
non-blocking" right in the middle.
Best regards,
--
Gonzalo Diethelm
DCV - Chile
Re: MINA and threads
Posted by Emmanuel Lecharny <el...@apache.org>.
gonzalo diethelm wrote:
> Although not strictly necessary, I would have the expectation that,
> since MINA is based on NIO, it should be possible to build a single
> executable that listens on a port and connects to itself on that port,
> all from a single thread. Is this possible at all?
>
No. As soon as you create an Acceptor, it spawns a new thread. Then as
soon as you accep an incoming connection, at least one new thread is
created to process the connection.
What you see in the logs is just plain normal The Main thread may ends,
but as you have at least one more existing thread.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org