On Tue, Dec 13, 2011 at 5:58 PM, Emmanuel Lecharny <elecha...@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)
