Consensus? Really?
On Aug 20, 2011, at 10:43 AM, Julien Vermillard wrote: > 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 >>
