SingleSessionIoHandlerDelegate

[Julien Vermillard <jv...@archean.fr>]

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

Re: Re : SingleSessionIoHandlerDelegate

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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 <el...@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

[Emmanuel Lecharny <el...@apache.org>]

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

[Squee <sq...@gmail.com>]

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.

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.

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.

On Wed, Mar 11, 2009 at 11:47 AM, Emmanuel Lecharny
<el...@apache.org> wrote:
> Squee wrote:
>>
>> 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.
>
> Why don't you use a Connector for that ?
>>
>> It then
>> synchronously waits for the session to connect before continuing.
>
> The Connector is just handling that for you ...
>>
>> 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).
>>
>
> Why not using a Connector for each protocol ?
>>
>> 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.
>>
>
> IMO, the 'multiton' pattern is not the best pattern ever. It's just a
> Hashmap containing many singleton. I don't see any advantage of having such
> a pattern implemented in MINA core.
>
> I don't mean that what you do is bad, Squee, what I just want to stress is
> that it's more or less the application designer to decide what to do with
> established connections, but it's not MINA responsability to implement any
> existing patterns.
>
> So, my question is : how hard would it be to switch to a multiton pattern to
> a simple map of Connectors ?
>
> --
> --
> cordialement, regards,
> Emmanuel Lécharny
> www.iktek.com
> directory.apache.org
>
>
>

Re: Re : SingleSessionIoHandlerDelegate

[Emmanuel Lecharny <el...@apache.org>]

Squee wrote:
> 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. 
Why don't you use a Connector for that ?
> It then
> synchronously waits for the session to connect before continuing. 
The Connector is just handling that for you ...
> 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).
>   
Why not using a Connector for each protocol ?
> 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.
>   
IMO, the 'multiton' pattern is not the best pattern ever. It's just a 
Hashmap containing many singleton. I don't see any advantage of having 
such a pattern implemented in MINA core.

I don't mean that what you do is bad, Squee, what I just want to stress 
is that it's more or less the application designer to decide what to do 
with established connections, but it's not MINA responsability to 
implement any existing patterns.

So, my question is : how hard would it be to switch to a multiton 
pattern to a simple map of Connectors ?

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org

Re: Re : SingleSessionIoHandlerDelegate

[Squee <sq...@gmail.com>]

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
<jv...@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 <sq...@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 <mb...@gmail.com>:
>> > Never used it.
>> >
>> > Maarten
>> >
>> > On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira
>> > <do...@yahoo.fr>wrote:
>> >
>> >>
>> >> +1 ...
>> >>
>> >>  Cordialement, Regards,
>> >> -Edouard De Oliveira-
>> >> http://tedorg.free.fr/en/main.php
>> >>
>> >>
>> >>
>> >> ----- Message d'origine ----
>> >> De : Emmanuel Lecharny <el...@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

[Julien Vermillard <jv...@archean.fr>]

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 <sq...@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 <mb...@gmail.com>:
> > Never used it.
> >
> > Maarten
> >
> > On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira
> > <do...@yahoo.fr>wrote:
> >
> >>
> >> +1 ...
> >>
> >>  Cordialement, Regards,
> >> -Edouard De Oliveira-
> >> http://tedorg.free.fr/en/main.php
> >>
> >>
> >>
> >> ----- Message d'origine ----
> >> De : Emmanuel Lecharny <el...@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

[Squee <sq...@gmail.com>]

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 <mb...@gmail.com>:
> Never used it.
>
> Maarten
>
> On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira <do...@yahoo.fr>wrote:
>
>>
>> +1 ...
>>
>>  Cordialement, Regards,
>> -Edouard De Oliveira-
>> http://tedorg.free.fr/en/main.php
>>
>>
>>
>> ----- Message d'origine ----
>> De : Emmanuel Lecharny <el...@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

[Maarten Bosteels <mb...@gmail.com>]

Never used it.

Maarten

On Mon, Mar 9, 2009 at 12:04 PM, Edouard De Oliveira <do...@yahoo.fr>wrote:

>
> +1 ...
>
>  Cordialement, Regards,
> -Edouard De Oliveira-
> http://tedorg.free.fr/en/main.php
>
>
>
> ----- Message d'origine ----
> De : Emmanuel Lecharny <el...@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 : SingleSessionIoHandlerDelegate

[Edouard De Oliveira <do...@yahoo.fr>]

+1 ...

 Cordialement, Regards,
-Edouard De Oliveira-
http://tedorg.free.fr/en/main.php



----- Message d'origine ----
De : Emmanuel Lecharny <el...@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: SingleSessionIoHandlerDelegate

[Emmanuel Lecharny <el...@apache.org>]

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: SingleSessionIoHandlerDelegate

[Emmanuel Lecharny <el...@apache.org>]

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
>   
After having done some investigation, it appears that the 
SingleSessionIoHandler class (and all the related classes) have been 
injected on revision 388103
(http://svn.apache.org/viewvc?view=rev&revision=388103).

There is a thread discussing the need for these classes, starting from 
this mail :
http://mail-archives.apache.org/mod_mbox/mina-dev/200603.mbox/%3C708A49D4-D659-4082-9716-004FC0F836C2@gmx.ch%3E

Here is the JIRA where this have been discussed, with the associated patch :
https://issues.apache.org/jira/browse/DIRMINA-187

Ok, I'm done with being an archeologist now :)

-- 
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org