On Aug 20, 2011, at 4:32 AM, Edouard De Oliveira wrote: > We shouldn't systematically copy the chain in the session as imho it's not so > usual to dynamically add filters in one particular session (the first case > that comes to my mind is dynamically protecting the session with ssl but it > requires a new connection most of the time no ? maybe some dynamic > compression or some negociation mechanism that will need a particular filter > wrapping and unwrapping messages)
There's been a fair bit of discussion on this before, this being the need for dynamically modifying filter chains in a session that's already being used. It is my assertion that it is an anti-pattern that signals the need for a state machine. Getting a protocol right on both ends is very hard and dynamic chains make it even more difficult. APIs should promote good practices With that said, look how complicated the implementation gets below. Just my 2 cents. Regards, Alan > > A copy on write strategy would improve memory footprint. So when would we > copy the chain ? when some change happens : add/remove filter > a chain controller could associate to the session it's alternative chain or > use the default one. > > So now what about threads coming into play ? using threadlocal seems a good > idea Em > > So to resume > - copy when necessary > - custom chain should be searched in the following places : threadlocal -> > session -> default chain of the controller > > ChainController.getChain() will hide this whole complexity providing > flexibility and efficiency wdyt ? > > Cordialement, Regards, > -Edouard De Oliveira- > ________________________________ > De : Emmanuel Lecharny <elecha...@gmail.com> > À : dev@mina.apache.org > Envoyé le : Samedi 20 Août 2011 9h29 > Objet : Re: [MINA 3.0] filter chains > > On 8/20/11 8:49 AM, Julien Vermillard wrote: >> Hi, >> Because a filterchain can be shared across different sessions and >> threads, so you need to pass the local chain index because you can >> store it locally in the filter chain. Perhaps there is something >> smarter to do, because it's the dark point of this API. > > The filter chain is copied into the session (at least, it was what was > done for MINA 2). Assuming that two different sessions might use two > different chains, and assumng that the chain might be dynamically > changed, it makes sense to do this copy. > > Now, if we can split the session (using an executor for instance), then > the chain must be copied. It would make sense to store the chain into a > ThreadLocal variable instead of storing it into a session object. >> >> Julien >> >> On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<l...@toolazydogs.com> >> wrote: >>> Why do we pass the current position? We also seem to pass it twice in the >>> method and the controller. >>> >>> >>> Regards, >>> Alan >>> >>> On Aug 19, 2011, at 1:10 PM, Julien Vermillard wrote: >>> >>>> Ok I committed the modification, for passing a chain controller to the >>>> filter for delegating the call to next filter. >>>> >>>> First I did it only for read& write chaining because the other events >>>> (created,open,closed,idle) are fine like they are. They don't need to >>>> block an event or send it multiple time to the following filter. >>>> >>>> Here the modified IoFilter, some controller interface are passed to >>>> read& write events : >>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/api/IoFilter.java >>>> >>>> >>>> Here sample implementation of LoggingFilter : >>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java >>>> >>>> Here the FilterChain implementation, still simple : >>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java >>>> >>>> Now I need to figure how to remove the current position argument of >>>> the filter call. >>>> >>>> Julien >>>> >>>> >>>> On Fri, Aug 19, 2011 at 2:46 PM, Julien Vermillard >>>> <jvermill...@gmail.com> wrote: >>>>> I half implemented the controller idea, it's looking like working, >>>>> I'll finish that during the weekend or next week and commit it for >>>>> review. >>>>> Julien >>>>> >>>>> On Fri, Aug 19, 2011 at 2:39 PM, Steve Ulrich<steve.ulr...@proemion.com> >>>>> wrote: >>>>>> Hi! >>>>>> >>>>>> Besides the points you mentioned, there are some other flaws: >>>>>> 1) How do you handle post-message-forwarding logic? >>>>>> 2) How do you handle filters that transparently push messages to the >>>>>> underlying filters (e.g. keep alive)? >>>>>> >>>>>> So the filters should decide about what to do, the chain about the where. >>>>>> >>>>>> regards >>>>>> >>>>>> Steve >>>>>> >>>>>> There could be specific (empty, single-result, multi-result) >>>>>> implementations that can be extended as needed. >>>>>> >>>>>>> Julien Vermillard [mailto:jvermill...@gmail.com] wrote: >>>>>>> >>>>>>> Hi, >>>>>>> I implemented some really simple chain for MINA 3 based on a list of >>>>>>> chain processed by a filter chain. >>>>>>> >>>>>>> The implementation is very simple, sounded like a good idea : >>>>>>> http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/or >>>>>>> g/apache/mina/filterchain/DefaultIoFilterChain.java >>>>>>> >>>>>>> But when i started implementing an HTTP codec I started to see the >>>>>>> real design issues. >>>>>>> The problem is when you need to produce more than one object during a >>>>>>> filter processing, like when you find more than one PDU in a >>>>>>> ByteBuffer. >>>>>>> >>>>>>> We could change IoFilter method : >>>>>>> Object messageReceived(IoSession session, Object message); >>>>>>> To : >>>>>>> List<Object> messageReceived(IoSession session, Object message); >>>>>>> >>>>>>> But starting to use collection here sound like an overkill and not >>>>>>> really a nice idea if we want to keep the memory usage low enough. >>>>>>> >>>>>>> So I'm scraping the current implementation, I'm going to try something >>>>>>> else suggested by Emmanuel : >>>>>>> When a filter want to call the next filter, he ask it to the filter >>>>>>> controller (aka the FilterChain). Let's see if it's going somewhere >>>>>>> this time ;) >>>>>>> >>>>>>> Julien >>> > > > -- > Regards, > Cordialement, > Emmanuel Lécharny > www.iktek.com
