[MINA 3] Filter's chain

[Emmanuel Lecharny <el...@gmail.com>]

Hi,

the current implementation of filter's chain is associating this chain 
to a service. In MINA 2, each session had a copy of this chain.

IMO, even if the default chain should be associated to the service, it 
would be a better idea to create a copy of this chain for each created 
session.

the rational behind this choice is that we then be able to add or remove 
a filter from the chain dynamically for one specific session. One 
obvious usage could be to add a logger when one would want to get some 
traces for one session, and not for the whole service. We can also 
imagine some other usages.

But it also has another direct advantage : currently, we compute the 
next filter to process in the DefaultIoFilterController, where an 
instance of the filter chain is stored. This DefaultIoFilterController 
is associated with a service, and can then be used by more than one 
selector, thus by more than one thread. That means we have to protect 
the current chain position for a given selector by storing it into a 
ThreadLocal. Access to the ThreadLocal values are way more expensive 
than accessing a session's current position if it's a simple integer.

It would be easier if the controller was totally stateless, which would 
be possible if the session was holding the filter's chain.  Now, that 
means we have to think about the way we should modify a chain for an 
existing session. Obviously, if we store the current position in the 
chain for a given session, we can't modify this position unless it's not 
0, otherwise we might have some bad errors (ArrayOutOfBoundException, 
for instance).

I still have to think a bit more about this, but I definitively think 
that it's a better approach.

Thoughts ?

-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Filter's chain

[Emmanuel Lécharny <el...@apache.org>]

On 12/14/11 2:17 PM, Julien Vermillard wrote:
> On Tue, Dec 13, 2011 at 5:58 PM, Emmanuel Lecharny<el...@gmail.com>  wrote:
>> Hi,
>>
>> the current implementation of filter's chain is associating this chain to a
>> service. In MINA 2, each session had a copy of this chain.
>>
>> IMO, even if the default chain should be associated to the service, it would
>> be a better idea to create a copy of this chain for each created session.
>>
>> the rational behind this choice is that we then be able to add or remove a
>> filter from the chain dynamically for one specific session. One obvious
>> usage could be to add a logger when one would want to get some traces for
>> one session, and not for the whole service. We can also imagine some other
>> usages.
>>
>> But it also has another direct advantage : currently, we compute the next
>> filter to process in the DefaultIoFilterController, where an instance of the
>> filter chain is stored. This DefaultIoFilterController is associated with a
>> service, and can then be used by more than one selector, thus by more than
>> one thread. That means we have to protect the current chain position for a
>> given selector by storing it into a ThreadLocal. Access to the ThreadLocal
>> values are way more expensive than accessing a session's current position if
>> it's a simple integer.
>>
>> It would be easier if the controller was totally stateless, which would be
>> possible if the session was holding the filter's chain.  Now, that means we
>> have to think about the way we should modify a chain for an existing
>> session. Obviously, if we store the current position in the chain for a
>> given session, we can't modify this position unless it's not 0, otherwise we
>> might have some bad errors (ArrayOutOfBoundException, for instance).
>>
>> I still have to think a bit more about this, but I definitively think that
>> it's a better approach.
>>
>> Thoughts ?
> Ok let's store de state (current chain position) in the session. that
> whould simplify the code (I'm not really happy with the thread local
> stuff)
Ok  will do that.


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [MINA 3] Filter's chain

[Julien Vermillard <jv...@gmail.com>]

On Tue, Dec 13, 2011 at 5:58 PM, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi,
>
> the current implementation of filter's chain is associating this chain to a
> service. In MINA 2, each session had a copy of this chain.
>
> IMO, even if the default chain should be associated to the service, it would
> be a better idea to create a copy of this chain for each created session.
>
> the rational behind this choice is that we then be able to add or remove a
> filter from the chain dynamically for one specific session. One obvious
> usage could be to add a logger when one would want to get some traces for
> one session, and not for the whole service. We can also imagine some other
> usages.
>
> But it also has another direct advantage : currently, we compute the next
> filter to process in the DefaultIoFilterController, where an instance of the
> filter chain is stored. This DefaultIoFilterController is associated with a
> service, and can then be used by more than one selector, thus by more than
> one thread. That means we have to protect the current chain position for a
> given selector by storing it into a ThreadLocal. Access to the ThreadLocal
> values are way more expensive than accessing a session's current position if
> it's a simple integer.
>
> It would be easier if the controller was totally stateless, which would be
> possible if the session was holding the filter's chain.  Now, that means we
> have to think about the way we should modify a chain for an existing
> session. Obviously, if we store the current position in the chain for a
> given session, we can't modify this position unless it's not 0, otherwise we
> might have some bad errors (ArrayOutOfBoundException, for instance).
>
> I still have to think a bit more about this, but I definitively think that
> it's a better approach.
>
> Thoughts ?

Ok let's store de state (current chain position) in the session. that
whould simplify the code (I'm not really happy with the thread local
stuff)