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
