Re: [MINA 3] Filter's chain
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)
Re: [MINA 3] Filter's chain
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
[MINA 3] Filter's chain
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
