mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <elecha...@gmail.com>
Subject Re: [MINA 3.0] Initial thoughts on FilterChain
Date Mon, 14 Dec 2009 09:16:37 GMT
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 ?)
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
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();

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

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

> Regards,
> Alan

Emmanuel Lécharny

View raw message