Re: Re : SingleSessionIoHandlerDelegate
No, as I already explained, Demuxing handler won't work. The demux handler determines which handler to use based on the individual messages, while we need to determine which handler based on the session. The messages are the same, but the handlers for different sessions are not. On Wed, Mar 11, 2009 at 2:01 PM, Emmanuel Lecharny elecha...@apache.org wrote: Squee wrote: Again, it's all the same protocol, so we're using the same filters on the connector, so there's not much reason to multiple connectors, we simply need multiple handlers. Part of the reason for doing it this way as well was because this was an existing architecture before we started using MINA to handle the actual connections, so it was a matter of fitting it best to MINA. That's make sense now. We had the same need on the server side for LDAP. What we did was to implemented a DemuxingIoHandler to manage those different handlers. Is that something you can do ? Again, I don't really care if the SingleSession stuff is removed from MINA as we'll just re-implement it easily enough ourselves. But there IS a use for doing it on the handler side rather than multiple connectors. yeah, I was trying to understand exactly what you meant. Thanks for the clarification. Also, as an aside, I believe there's no hashmap involved in the multiton here...I believe each handler is simply put as an attribute on each session. the attributes are stored in a Hashmap in the session :) Thanks a lot for the clarification. I'm just trying to evaluate the impact of moving out this part of MINA core, as we never used. As you did, it's interesting to have a clear vision of what this class can be used to. -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
Yes, that's correct. And that's why our DataChannel classes establish the connection; they're the handlers for that session. It's also why we have slightly modified the SingleSessionIoHandlerDelegate so that we can specify ahead of time the handler to use. The one in MINA creates the handler from a factory, which is slightly less useful unless you can tell from the session itself what to do. In other words, we do this: 1. Create a new handler based on what we need for this connection 2. Establish a new connection 3. Set the new session to use the created handler 4. Repeat for other connections using different handlers. On Wed, Mar 11, 2009 at 2:24 PM, Emmanuel Lecharny elecha...@apache.org wrote: Squee wrote: No, as I already explained, Demuxing handler won't work. The demux handler determines which handler to use based on the individual messages, while we need to determine which handler based on the session. The messages are the same, but the handlers for different sessions are not. Let me see if I understand the full context : - you establish a session, and doing so, you associate a handler to it - then this handler is triggered when message are exchanged. Q : how do you determinate which handler to select when establishing the session ? Is there any external criterium for that ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
Yes, we could I suppose, but it's kinda handy to have only one connector to manage, especially when we need to shut it down and close connections, rather than running to every connector to close it down. Either way works, but it's definitely easier to use a single connector. That was one thing we liked about moving to MINA from using Sockets directly and managing that kind of thing ourselves. And of course all of the other benefits MINA provides :) On Wed, Mar 11, 2009 at 3:11 PM, Emmanuel Lecharny elecha...@apache.org wrote: Squee wrote: Yes, that's correct. And that's why our DataChannel classes establish the connection; they're the handlers for that session. It's also why we have slightly modified the SingleSessionIoHandlerDelegate so that we can specify ahead of time the handler to use. The one in MINA creates the handler from a factory, which is slightly less useful unless you can tell from the session itself what to do. In other words, we do this: 1. Create a new handler based on what we need for this connection 2. Establish a new connection 3. Set the new session to use the created handler 4. Repeat for other connections using different handlers. but then you can also do : 1. Create the needed handler for your connection 2. Configure a Connector with this handler, injecting the filters you need in the chain 3. Establish the connection 4. Repeat this with some other Connectors No ? Did I missed something ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
Well, since one single connector is managing all the session, we can access and close all session from there, rather than managing our own list of connectors separately. Again, a minor difference. We don't go through and close DataChannel objects, just sessions on the connector (and rely on sessionClosed() call on datachannels to handle any cleanup) And yes, DataChannel objects simply call connect on the connector...Again, the DataChannels were from a previous architecture before we were using MINA. They aren't particularly useful, but they're not changing to prevent massive refactoring of the interface the rest of the app uses. On Wed, Mar 11, 2009 at 4:20 PM, Emmanuel Lecharny elecha...@apache.org wrote: Squee wrote: Yes, we could I suppose, but it's kinda handy to have only one connector to manage, especially when we need to shut it down and close connections, rather than running to every connector to close it down. Either way works, but it's definitely easier to use a single connector. That was one thing we liked about moving to MINA from using Sockets directly and managing that kind of thing ourselves. And of course all of the other benefits MINA provides :) There is still something mysterious to me : if you manage more than one session, then you have more than one DataChannel opened. You will have to close them anyway, one by one. If you use Connector instead you just have the same problem, without the burden to use the SingleSessionIoHandler class. A Session is associated to a single connection anyway. If you have sequential sessions (ie, you establish a new one when you're done with the previous one), you just havs to switch the handler when switching the session. If you have parallel sessions, then you can use as many connectors as needed to handle all the sessions, and each session will have its own handler. In any case, you just have to call connect(SocketChannel handle, SocketAddress remoteAddress), which will deal with all the details you are handling on your side not using a connector atm... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
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. 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 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). 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. 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... 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. On Wed, Mar 11, 2009 at 5:28 PM, Emmanuel Lecharny elecha...@apache.org wrote: Squee wrote: Well, since one single connector is managing all the session, A MINA Connector can manage only one session at the time. Are we talking about the same Connector here ? -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
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
Re: Re : SingleSessionIoHandlerDelegate
Well, I'd have to go look at the code again to be fully sure, but we have a client layer built on top of MINA for the GUI part of our app, where we pull a ton of data from a remote server for viewing. When a GUI element needs data for its local cache, it creates a DataChannel object which performs the necessary connections with MINA. It then synchronously waits for the session to connect before continuing. The DataChannel class is a SingleSessionIoHandler implementation, and our IoHandler is a SingleSessionIoHandlerDelegate. Each DataChannel subclass provides different IoHandler functionality (same protocol, different roles and data to manage). This allows us to have completely different handlers for the different data caches, while still using the same protocol messages for each cache. (i.e. a response from the server to clear the local cache is exactly the same, but handled differently depending on the data) This is preferable in this instance over the demuxing for this reason, as well as the encapsulation that having all of our data handling on our DataChannel IoHandlers helps with. The biggest problem I had with it was that I had to subclass SingleSessionIoHandlerDelegate to allow us to use our already created DataChannel class (again, an implementation of SingleSessionIoHandler), rather than creating them AFTER the session was created, but that's probably very specific to our way of using it. Basically, our version doesn't use the factory and sets the session on an existing specified SingleSessionIoHandler when the session is created. On Tue, Mar 10, 2009 at 2:38 AM, Julien Vermillard jvermill...@archean.fr wrote: Ok so, why not keep it ? Would be a great help if you can explain how it's working and how it's suposed to be used. Julien Le Mon, 9 Mar 2009 13:07:34 -0600, Squee squees...@gmail.com a écrit : I actually use it in our product, though I believe I subclass the handler rather than using it directly. If the functionality is removed, it's not HUGE loss and I can just do it myself, but it is useful for certain applications. 2009/3/9 Maarten Bosteels mbosteels@gmail.com: Never used it. Maarten On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira doe_wan...@yahoo.frwrote: +1 ... Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Emmanuel Lecharny elecha...@apache.org À : dev@mina.apache.org Envoyé le : Lundi, 9 Mars 2009, 11h57mn 27s Objet : Re: SingleSessionIoHandlerDelegate Julien Vermillard wrote: Hi, someone use the SingleSessionIoHandlerDelegate and the org.apache.mina.handler.multiton package ? I feel like CTRL+A DELeting it, except someone use it. Julien I don't even know what is this good for ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Re : SingleSessionIoHandlerDelegate
I actually use it in our product, though I believe I subclass the handler rather than using it directly. If the functionality is removed, it's not HUGE loss and I can just do it myself, but it is useful for certain applications. 2009/3/9 Maarten Bosteels mbosteels@gmail.com: Never used it. Maarten On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira doe_wan...@yahoo.frwrote: +1 ... Cordialement, Regards, -Edouard De Oliveira- http://tedorg.free.fr/en/main.php - Message d'origine De : Emmanuel Lecharny elecha...@apache.org À : dev@mina.apache.org Envoyé le : Lundi, 9 Mars 2009, 11h57mn 27s Objet : Re: SingleSessionIoHandlerDelegate Julien Vermillard wrote: Hi, someone use the SingleSessionIoHandlerDelegate and the org.apache.mina.handler.multiton package ? I feel like CTRL+A DELeting it, except someone use it. Julien I don't even know what is this good for ... -- -- cordialement, regards, Emmanuel Lécharny www.iktek.com directory.apache.org
Re: Why ConnectFuture.isConnected() returns true while there there is no server?
While I've never actually used Mina's UDP yet, you need to keep in
mind that UDP doesn't use connections. I believe the Datagram
connector simply does nothing when you connect with it; no traffic
is sent to the server. So, a UDP session will always be connected
and a connect attempt will always be successful. Or at least, that's
what I assume.
If you need to know whether you've successfully connected to a server,
use TCP instead (NioSocketConnector).
On Sun, Dec 28, 2008 at 9:59 AM, hezjing hezj...@gmail.com wrote:
Hi
I have a method to connect to a UDP server,
private void connect(String hostname, int port) {
logger.debug(Entered connect());
NioDatagramConnector connector = new NioDatagramConnector();
ConnectFuture future = connector.connect(new
InetSocketAddress(hostname, port));
future.awaitUninterruptibly();
future.addListener(new IoFutureListenerConnectFuture() {
public void operationComplete(ConnectFuture future) {
if (future.isConnected()) {
logger.debug(...connected);
} else {
logger.error(Not connected...exiting);
}
}
});
logger.debug(Exiting connect());
}
when run without starting any UDP server (on Windows XP), the program prints
the following on the console
Entered connect()
...connected
Exiting connect()
Why future.isConnected() returned true while there isn't any server running?
--
Hez
Re: [About the Filter Chain] Proposals
As a user of Mina, I agree 100% on releasing 2.0 without all of these big changes, and pushing them down to a 3.0 release. While I'm perfectly willing and able to update my app code if 2.0 API changes (I expected as much when I chose to go with 2.0), it's still nice to be using fully released software, rather than pre-release-candidate stuff. (Not that I've had any issues at all.) On Mon, Nov 3, 2008 at 9:38 AM, Niklas Gustavsson [EMAIL PROTECTED] wrote: On Mon, Nov 3, 2008 at 4:13 PM, Mark Webb [EMAIL PROTECTED] wrote: I think we should focus on getting 2.0 out the door. We have been working on it long enough and I think there are many people using it in production or near-production systems. Once we release, we will probably get alot more feedback and can use that feedback to enhance/fix the next version. Big +1. We will find areas that we would like to improve during the foreseeable future (this change and ByteBuffer comes to mind). Including all such changes will delay 2.0 for a long time, long enough for MINA to get behind other frameworks. Having a real release out will mean getting further feedback from users, so far I haven't seen a lot of users requesting this change nor the ByteBuffer change. I think we're too critical, the code is great. Release early, release often. We do neither. I would think that we should move right towards 3.0. I say go work on a branch (as already suggested) and see where that leads. /niklas
Re: [About the Filter Chain] Proposals
One other benefit to splitting it into two chains is it clarifies the order for a user. I only started using Mina a couple months ago, and one of the first things I got tripped over was the order the filters were called when a message was received vs. sent. My initial code had the filters in the reverse order of what they should be, because it wasn't clear which order they'd be called in for each case (not even in the documentation!) Splitting it into two chains would solve this issue completely. Also, I'd like to make a plug for removing messageSent() callbacks and having the end-user API rely on WriteFutures instead. It's a hassle to write new filters when you have to worry about passing back the correct object. Oh, and one thing to keep in mind, whether or not filter chains are split into two, is that there are some filters that requires messages to be sent in the opposite direction currently, i.e. the SSLFilter. Looking through the SSLFilter, a lot of extra hidden complexity is created when the filter has to store references to the next filter in the chain so it can send the SSL protocol messages in response; this also breaks the ability for filter chains to be modified correctly (usually not a problem with SSLFilter, but could be with other filters). I'm not sure how this would work with a split filter chain, but there needs to be an API to automatically inject messages at specific points in the filter chain and bypass other filters (such as the protocol filter) so that multiple-level protocols, such as SSL wrapping, can be handled better. On Thu, Oct 30, 2008 at 6:28 PM, Emmanuel Lecharny [EMAIL PROTECTED] wrote: Proposition (a) : Let's create two chains instead of one : a reader-chain/incoming-chain and a writer-chain/outgoing-chain.
