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
