Hmm consensus about copy on write chain is already here no ? Wanna try to implements ? ;)
On Sat, Aug 20, 2011 at 1:32 PM, Edouard De Oliveira <[email protected]> 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) > > 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 <[email protected]> > À : [email protected] > 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<[email protected]> >> 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 >>>> <[email protected]> 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<[email protected]> >>>>> 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:[email protected]] 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 >
