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] filter chains
Date Fri, 19 Aug 2011 12:16:26 GMT
On 8/19/11 1:55 PM, Alan D. Cabrera wrote:
> On Aug 19, 2011, at 4:16 AM, Julien Vermillard 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/org/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 ;)
> I ran into a different scenario that dictated the same result.  For me, often times when
a message is sent or received no message is passed on so my protocol had to always return
a null.  This always seemed awkward to me.  Also, then that dictated that I had to check for
nulls in the framework, also not so good.
> Take a look at my class org.apache.mina.link.UpState to see what I mean.

We should not compare filters and pipes. Think about the whole mechanism 
as if it was a state machine, because it is. The only relation between 
two states are those dicatetd by the transition we allow. We don't 
transite from one state to another one randomly, so are the data passed 
from one state to another : they are well known by both the initial and 
the final states.

We should then make no general presumption about the received and sent 
data. If one state does not require anything, fine : the caller will 
know it. OTOH, if we can have multiple data to send to the next state, 
then we just have to loop and call as many times the next step as necessary.

At least, this is my vision...

Emmanuel L├ęcharny

View raw message