[email protected] wrote:
Zitat von Ashish <[email protected]>:
On Tue, Oct 27, 2009 at 3:14 PM, <[email protected]> wrote:
Well, I use version 2.0M6 and I have trouble with the order of filters.
I created a protocol encoder/decoder and some filters. The filters
extend IoFilterAdapter and overwrite messageReceived/Sent.
This works well for for inbound messages, the protocol is used first
and than the filters are used on their order.
The trouble starts outbound. I would expect that the filter chain is
processed in the reverse order but id did not! The filters are called
in the same order as the for the inbound messages. Is this the designed
behaviour? Any ideas?
This is how it works today :-(
This is going to change in 3.0, where we plan to have different chains
for incoming and outgoing messages.
It shall be a while before you get to use 3.0
I do not understand why you need two chains?
Just because you don't need to do the same work in both ways. Typically,
you may want to split the encoder and the decoder in two different
filters. You may also avoid havng to pass through an executor when
writing data back to the client.
In any case, having two chains is most certainly simpler to deal with
(that does not mean we expose those two chains to the user if not needed).
The filters are bidirectional,
messageReceived and messageSent. The only issue is the order, because
it does not work as described in the wiki. The session.write method
should only call the filters in the reverse order.
No. The wiki is representing a flow which is not correct, but that does
not mean the code is broken. We have tens of applications based on MINA
which works perfectly well, I don't see any issue considering that you
won't have tens of filters in the chain anyway (the most you can pile up
is probably four : a codec, a SslFilter, an executor and a logging
filter). Generally speaking, two of them are probably enough : SSL and
codec.
I want to use a protocol, filter 1-5 and a handler. The handler should
be able to send back a message. The message back should be processed by
filter 5,4,3,2,1 and the protocol. That's how I interpret the
architecture
diagram on the wiki and how it makes sense for me.
But the diagram is just to express that messages are going through the
filters and back to the client. Probably need an extra explaination to
eliminate possible confusion about the order.
For me the current
behaviour is a bug, it simply doesn't make sense.
I would rather claim that it's confusing. It's certainly not a bug.
I dare the claim that
nobody implemented sent and receive in one filter.
Wrong ! If you don't need SSL, then a codec is enough. Apache Directory
Server implements NTP protocol with one single filter.
I created an issue (DIRMINA-744) just before I read your answer.
The only solution I see is that each filter has to find the next
filter by
itself.
If you read the code, this is *exactly* what the code does. But the way
it find the next filter is just by reading the chain :)
We are thinking about another approach, as Ashish axplained, which is
certainly easier to understand. Anyway, both approach will work...
Keep in mind that you may not implement an action (ie, messageSent) in a
filter if not needed. The filter will then be bypassed.
It could use the session to get the filter chain, find myself and
call messageSent of the predecessor. No comment about quality of code.
Since I think the changes in MINA are minimal to reverse the order
for sending. How about an option/configuration that changes the order?
The filter chain already has a method getAllReversed(). This would allow
to match the architecture diagram on the wiki on one hand and allow
compatibility where it is needed.
Wed'd rather think about defining the two chains and let the user
configure it. In any case, that will end with the same result.
What's is puzzling is that the current implementation, no matter how
weird it sounds to you, and no matter how irrelevant is the doco (!) is
doing its job fine :)
In any case, can you just tell us about your implementation problem, so
that we can give you a hand ?
Thanks !
--
--
cordialement, regards,
Emmanuel Lécharny
www.iktek.com
directory.apache.org
