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:31:53 GMT

On Dec 13, 2009, at 8:22 PM, Ashish wrote:

>> 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?
>
> Sorry , but I am confused :-(
> can you help me understand how the Filter chains as a state would  
> work?
>
> Here is a simple Chain. The one with * can be dynamically
> added/removed. Logging filter could be added at multiple places
>
> Acceptor -> BlackList Filter -> Logging Filter* -> Throughput Filter*
> -> Executor Filter -> Codec -> Logging Filter *
> ->IoHandler
>
> Now how would the suggested approach work??
>

By previous posts we agreed that there is no need to dynamically add  
and remove filters in an ad hoc manner; it was merely a mechanism to  
simulate a state machine.   Earlier in this thread we discussed how  
the state machine would fit into the Mina architecture:

It's my opinion that new filters get created to simulate state machine  
changes and any other use is an ad hoc mechanism that can be more  
cleanly refactored into a state machine mechanism.  With that said aa  
session w/  N fixed chains where each chain represents a state would  
fit the bill.  The number of states is fixed.  The composition of the  
state machine can be changed until the acceptor/connector have  
established the connection.

Acceptor -> ChainMachine -> IoHandler

inside the chain machine:

S1: IOF1 -> IOF2 -> IOF3  -> IOF5 -> IOF4
S2: IOF1 -> IOF3 -> IOF5 -> IOF4
S3: IOF1 -> IOF2 -> IOF3 -> IOF4

 From a user's perspective things are quite easy to grok and most  
cases the chain machine degenerates into a single state chain.


The above state machine supported your example of changing state chains:

              /  IOF->IOF2->IOF3->IOF5->IOF4->IoHandler
Acceptor->IOF1->X->IOF3->IOF5->IOF4->IoHandler
              \ IOF1->IOF2->IOF3->X->IOF4->IoHandler

Regards,
Alan



Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message