On 12/14/11 2:17 PM, Julien Vermillard wrote:
On Tue, Dec 13, 2011 at 5:58 PM, Emmanuel Lecharnyelecha...@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
