mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alan D. Cabrera" <l...@toolazydogs.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 16:39:46 GMT

On Dec 14, 2009, at 1:16 AM, Emmanuel Lecharny wrote:

> Alan D. Cabrera a écrit :
>> On Dec 13, 2009, at 2:42 AM, Emmanuel LŽcharny wrote:
>> <snip/>
>>>> The key thing about state machines is that the states and the  
>>>> transitions are known and fixed ahead of time. If this our state  
>>>> of affairs, and I think that it is, then things are much more  
>>>> simple and mentally tractable, i.e. there's no ad hoc filter  
>>>> creation during protocol processing and much of the threading  
>>>> issues in past entries on this thread disappear.
>>> Generally speaking, when implementing a protocol, states and  
>>> transitions are very well known and static, so the SM approach  
>>> seems adequate.
>> Agreed, the SM approach should cover all cases; even the logging  
>> case in your subsequent post.
>> So with that said, would it not make sense to have a set of fixed  
>> filter chains w/ each chain representing a state rather than a  
>> bucket of filters with each filter deciding the next filter to  
>> execute?
> Not necessarily, for three reasons :
> 1) if the chain is fixed at startup, you can't anymore inject a  
> LoggingFilter when the server is running. You can only activate or  
> desactivate it. Not that it's realy a big issue, but it may help in  
> some case (that also mean we have a way to control the execution.  
> JMX ?)

One normally doesn't turn on and off things like that on a per message  
basis.  What I mean by that is that each filter decides to do what it  
needs to do.  That includes logging.  Constantly injecting logging  
filters on an ad hoc basis is a very, very, poor practice.

> 2) Most important, if we don't have a clue about which is the next  
> filter in the chain, that leads to problem when debugging, as you  
> can't know which filter will be called. Ennoying

Sure you do.  The chains are fixed.  If you know what filter you are  
and what state you're in you know what filter gets called next from  
the perspective of the framework.  From the perspective of the filter  
you shouldn't care what's next, if you do then you've introduce a  
brittle dependency.  For me that;s usually a red flag that I haven't  
thought through a design and it needs to be revisited.

> 3) Last, not least, we want to be able to call the next filter in  
> the middle of a processing :
> messageReceived() {
> do blah();
> if ( condition ) {
> do anotherBlah();
> call Next filter();
> } else {
> do yetAnotherBlah();
> call nextFilter();
> }
> do endingBlah();
> }

That just tells me that you have mixed up two states into one and that  
you need to expend a little more effort into your state machine design.

> Not sure this is possible in another way than with those computed  
> nextFilter() inside the filters.

I agree but it's my contention that it's a bad practice that supports  
an ill thought out protocol.

> (well, t's always possible to express this with more transitions and  
> states, but t would be more complicated to write filters then...)

I'm looking at your messageReceived() method and am thinking that you  
have provided me with a perfect example for state programming.  Only  
the original author of that method would know what's going on.


View raw message