I was thinking about this page : https://cwiki.apache.org/confluence/display/MINA/MINA+3.0+design
Look like you have comments about CoW chain, can you please elaborate ? Julien On Sat, Aug 20, 2011 at 10:29 PM, Alan D. Cabrera <l...@toolazydogs.com> wrote: > 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 >> <doe_wan...@yahoo.fr> 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 <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 >>> > >
