Ok, looks like we're on the same page regarding connectors again :) And yes, it would be really nice if DemuxIoHandler could demux on session attributes as well as messages (or even both at the same time), and would definitely be great in 3.0.
On Wed, Mar 11, 2009 at 7:36 PM, Emmanuel Lecharny <elecha...@apache.org> wrote: > 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 > > >
