Thanks,got it, I Will try to implement that tomorrow. -- Julien Vermillard
Le 20 août 2011 à 09:30, Emmanuel Lecharny <elecha...@gmail.com> a écrit : > 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 >
