Squee wrote:
Hrm, well, if that is the case, then there are two problems: 1) We're
connecting with multiple sessions just fine one one connector and 2)
The documentation does not specify this anywhere that I can see.
I'm sorry, my bad. I have made a confusion between the concept of
'connection' and the way Connector works internally (ie, using a single
selector to manage all the incoming and outgoing data).
I'm also used to manage a few number of connections on the client side
(ie, few = 1 :), so it feels quite natural to define a Connector for
this connection (because, eh, otherwise, you _can't_ manage a connection
without any connector !).
It's also late here, I must be a bit tired now ...
Since they're both IoServices, which appear to handle multiple
sessions each, that was my assumption, and it's been running fine that
way for many months....
You are correct.
In honesty, I don't think it makes sense to enforce one session per
IoConnector, since that implies separate processing threads handling
multiplexing for a single connection each (by default).
Yup. The problem here is the semantic. Connector manages connection,
it's different from a Connection. My bad.
You could all
use the same IoProcessor of course, but is that also necessary over
one connector? Is that really how it's supposed to be? The
NioSocketConnector (not that I ever use that directly) uses the same
interface as the Acceptor, allowing for multiple socket handles, etc.,
so there doesn't appear to be any real difference in usage.
There is no difference, except that you don't handle the ACCEPT event in
a Connector. Btw, there is a design problem in the way Selectors are
used. Right now, the Selector is handled by the IoProcessor, which is a
big mistake. It should be associated with the Acceptor/Connector. This
is something I don't like in MINA 2.0 and that I would like to be
changed in MINA 3.0. There is no good reason to have as many selector as
you have IoProcessor, plus it's dangerous, as you may block a set of
socket if one of them blocks in the IoProcessor, as the whole thread
will be blocked.
Instead of that, with a single selector associated with the
Acceptor/Connector, and an executor to spread the load, you can
guarantee that every single connection will be equally treated even if
some connection are blocked for any reason, as soon as you have
reamining threads in the executor. Anyway, this is a digression...
The implication of both Connector and Acceptor using the same
IoService is that you can use them similarly. Only difference is one
you accept incoming sessions and the other you connect new outgoing
sessions, and there's no indication of a limit or difference in
needing to create many Connectors vs. one Acceptor. As I read through
all the documentation, my assumption has always been that they worked
similarly, allowing many sessions per connector. That way, connection
can be pre-configured with filters, etc. just once, then reused as
needed to create new sessions. I found this to be one of the better
aspects of MINA was that ability to do connection configuration just
once if you wanted...
You are plain right.
It it's only supposed to be one IoConnector per session, then the
documentation needs to be MUCH more clear. And the code should produce
errors when trying to do so, as our code is working perfectly fine
with multiple simultaneous session per connector.
No, I'm wrong. Now, assuming you have a single connector, and multiple
connection, ie multiple session, I think that MINA is lacking of a
session based handler selection mechanism there. The Demux handler will
pick and handler based on a message type, and what you want to do is to
pick a handler based on some other parameter, which has been stored in
the session. It could have been done in a better way if only the
DemuxIoHandler have had a way to define how to select the handler (a
kind of selector helper method). This is not the case, instead you have
a complex mixup of concepts including the multiton package you are
using. That's sad... But I now understand why you used it.
Ok, I think it's better to keep in in 2.0, and change it in 3.0 then.
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
