So your idea would be to ditch the chain and replace it with a FSM framework ? It's what you are trying to implements here ? http://svn.apache.org/repos/asf/mina/sandbox/adc/ahc/mina3/src/main/java/org/apache/mina/core/state/StateMachineChannel.java
On Sun, Aug 21, 2011 at 2:09 AM, Alan D. Cabrera <l...@toolazydogs.com> wrote: > Wow, I totally forgot about these pages. > > There's been a fair bit of discussion on this topic on the mailing list > 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 network endpoints is very hard and dynamic chains make it even > more difficult and error prone. APIs should promote good practices. > > There are implementation issues as well. Look how complicated the > implementation, sketched by Edouard, gets below. > > Normally I'm a let a thousand flowers bloom kind of guy. But, as you know, > I've been a strong advocate of thinning Mina's bloated class library. I find > it difficult justifying CoW chains in a library that people already find > bewildering. > > Just my 2 cents. Let's get this finally resolved as this topic seems to pop > up on a regular basis. > > > Regards, > Alan > > On Aug 20, 2011, at 2:10 PM, Julien Vermillard wrote: > >> 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 >>>>> >>> >>> > >
