directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Niklas Therning <nik...@trillian.se>
Subject Re: [mina] IoFilters: DIRMINA-121 / 122
Date Mon, 14 Nov 2005 20:42:21 GMT
Irving, Dave wrote:

>Hi,
>
>Im just starting to have a look at this now - and I have a couple of
>questions.
>If you could help me in clearing them up that would be greatly
>appreciated:
>
>  
>
>>Today we have SocketSessionManagerFilterChain,
>>    
>>
>DatagramSessionManagerFilterChain, and so on. 
>  
>
>>This makes it hard to combine arbitrary IoFilterChains into longer
>>    
>>
>chains which is 
>  
>
>>required for DIRMINA-121.
>>    
>>
>
>Agreed
>
>  
>
>>Add a new interface which is the counter part of IoHandler. 
>>I don't have a good name for it, let's call it IoProcessor for now. 
>>IoProcessor looks something like this:
>>    
>>
>
>  
>
>>public interface IoProcessor {
>>   void write( IoSession session, WriteRequest writeRequest );
>>   void close( IoSession session, CloseFuture closeFuture ); }
>>    
>>
>
>The way I understand this is that the concrete "do a write / do a close"
>behaviour used to be embedded in the concrete filter chain
>implementations. E.g: SocketSessionManagerFilterChain knows how to do a
>"real" write / close for a socket session. What we are doing here is
>extracting this behaviour in to a sort of "strategy" interface which we
>can plug in to any chain. Correct?
>
>  
>
Absolutely correct!

>>Add some methods to the IoFilterChain interface:
>>    
>>
>
>  
>
>>void setIoProcessor( IoProcessor p );
>>    
>>
>
>Makes sense if Im correct above. I.e: plug in the "processor" strategy
>for the chain.
>
>  
>
>>void sessionOpened( IoSession session, IoHandler h ) throws Exception;
>>    
>>
>
>  
>
>>void sessionClosed( IoSession session, IoHandler h ) throws Exception;
>>    
>>
>
>  
>
>>void messageReceived( IoSession session, Object message, IoHandler h )
>>    
>>
>throws Exception; ... 
>  
>
>>(I think you get the point)
>>    
>>
>
>Replacing the sessionOpened(IoSession) / sessionClosed(IoSession) et al
>methods in AbstractFilterChain?
>  
>
Yes.

>  
>
>>These are exactly the same as the methods in IoHandler except that the
>>    
>>
>extra IoHandler argument has been added. > > The idea is that this
>should be propagated through the chain (embedded in the NextFilter
>class)
>
>This is where my real question comes in: You say later that we shouldn't
>need to refactor existing filter implementations. 
>How are we going to pass the handler through transparently without
>changing the IoFilter / NextFilter interface?
>I think this is the bit Im missing at the moment :o)
>
>  
>
And that's where things get really tricky! ;-)    Actually when I have a
look at the code now I see that the concrete NextFilter instances are
created only once and then used all the time. If my idea is going to
work the NextFilter objects created by AbstractIoFilterChain will have
to be created on each filter invocation. We need a new NextFilter
implementation. Here's an example:

    public static class UpstreamNextFilter implements NextFilter {
        Entry head;
        IoHandler handler;
        public UpstreamNextFilter(Entry head, IoHandler handler) {
            this.head = head;
            this.handler = handler;
        }
        public void sessionCreated( IoSession session )
        {
            if (head != null) {
                head.filter.sessionCreated(new
UpstreamNextFilter(head.nextEntry, handler), session);
            } else {
                handler.sessionCreated(session);
            }
        }
        public void sessionOpened( IoSession session )
        {
            if (head != null) {
                head.filter.sessionOpened(new
UpstreamNextFilter(head.nextEntry, handler), session);
            } else {
                handler.sessionOpened(session);
            }
        }
        public void sessionClosed( IoSession session )
        {
            if (head != null) {
                head.filter.sessionClosed(new
UpstreamNextFilter(head.nextEntry, handler), session);
            } else {
                handler.sessionClosed(session);
            }
        }
        ... (I think you get the point)

In AbstractIoFilterChain sessionCreated() would look something like:

    public void sessionCreated( IoSession session, IoHandler handler )
    {
        Entry head = this.head;
        new UpstreamNextFilter(head, handler).sessionCreated(session);
    }

There would also be a corresponding DownstreamNextFilter implementation
(perhaps Upstream and Downstream can be combined into one) which takes
an IoProcessor in its constructor instead of an IoHandler.

One thing that strikes me now is that the NextFilter interface is almost
the union of IoHandler and IoProcessor. Except that the methods of
NextFilter aren't allowed to throw Exception. Maybe that fact could be
used to simplify the API?

I hope this made any sense. It works in my head but that doesn't have to
mean anything! ;-)

/Niklas


Mime
View raw message