On 8/20/11 8:49 AM, Julien Vermillard wrote:
Hi,
Because a filterchain can be shared across different sessions and
threads, so you need to pass the local chain index because you can
store it locally in the filter chain. Perhaps there is something
smarter to do, because it's the dark point of this API.
The filter chain is copied into the session (at least, it was what was
done for MINA 2). Assuming that two different sessions might use two
different chains, and assumng that the chain might be dynamically
changed, it makes sense to do this copy.
Now, if we can split the session (using an executor for instance), then
the chain must be copied. It would make sense to store the chain into a
ThreadLocal variable instead of storing it into a session object.
Julien
On Sat, Aug 20, 2011 at 12:41 AM, Alan D. Cabrera<[email protected]> wrote:
Why do we pass the current position? We also seem to pass it twice in the
method and the controller.
Regards,
Alan
On Aug 19, 2011, at 1:10 PM, Julien Vermillard wrote:
Ok I committed the modification, for passing a chain controller to the
filter for delegating the call to next filter.
First I did it only for read& write chaining because the other events
(created,open,closed,idle) are fine like they are. They don't need to
block an event or send it multiple time to the following filter.
Here the modified IoFilter, some controller interface are passed to
read& write events :
http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/api/IoFilter.java
Here sample implementation of LoggingFilter :
http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filter/logging/LoggingFilter.java
Here the FilterChain implementation, still simple :
http://svn.apache.org/repos/asf/mina/branches/3.0/core/src/main/java/org/apache/mina/filterchain/DefaultIoFilterChain.java
Now I need to figure how to remove the current position argument of
the filter call.
Julien
On Fri, Aug 19, 2011 at 2:46 PM, Julien Vermillard
<[email protected]> wrote:
I half implemented the controller idea, it's looking like working,
I'll finish that during the weekend or next week and commit it for
review.
Julien
On Fri, Aug 19, 2011 at 2:39 PM, Steve Ulrich<[email protected]> wrote:
Hi!
Besides the points you mentioned, there are some other flaws:
1) How do you handle post-message-forwarding logic?
2) How do you handle filters that transparently push messages to the underlying
filters (e.g. keep alive)?
So the filters should decide about what to do, the chain about the where.
regards
Steve
There could be specific (empty, single-result, multi-result) implementations
that can be extended as needed.
Julien Vermillard [mailto:[email protected]] 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/or
g/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 ;)
Julien
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
