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
