directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [mina] IoFilters: DIRMINA-121 / 122
Date Tue, 15 Nov 2005 12:49:50 GMT
Recreating the chains on every invocation sounds like a very expensive
price to pay on every call. What is exactly the benefit we will be
getting out of it?

> -----Original Message-----
> From: Niklas Therning [mailto:niklas@trillian.se]
> Sent: 14 November 2005 20:42
> To: Apache Directory Developers List
> Subject: Re: [mina] IoFilters: DIRMINA-121 / 122
> 
> 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