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 23:53:54 GMT
On 8/19/11 2:29 PM, Alan D. Cabrera wrote:
> On Aug 19, 2011, at 5:16 AM, Emmanuel Lecharny wrote:
>
>> 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.
> I'm not sure that I'm following.  What is this data that you speak of?

Let me clarify my thought : I'm talking about any data transiting from 
one filter to another. If it's from the socket to the first filter, then 
it's a ByteBuffer. If it's between the decoder and the Handler, then 
it's a protocol message. Etc.
>
>> 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.
> I'm not sure that I'm following.  Who is the caller and why does he need to know all
this?

Simply because the kind of data the receiver will process has to be a 
data it *can* handle. A decoder is supposed to receive some bytes and 
transform them to a message. But we can also imagine a 2 layers decoder, 
and then the second decoder will expect a message, not some bytes.

One example : in LDAP, we received PDU, which contains TLVs 
(Type/length/value). Then we transform those TLVs into LDAP message.
The first decoder will transform bytes to TLVs;
The second decoder will transform the TLVs to LDAP messages 
(searchRequest, etc);

Here, the second decoder won't be able to do anything if it receives 
some ByteBuffer, so the caller (the first decoder) *must* know what the 
second decoder will accept, otherwise you'll get some nasty exception.

Is it clearer?


PS : That's the problem when both of us are not english fluent... When I 
write a mail (a message), I'm losing some context, and you can't decode 
exactly what I had in mind when I wrote it. Sorry for that :/


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message