directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <dave.irv...@logicacmg.com>
Subject RE: [mina] IoFilters: DIRMINA-121 / 122
Date Tue, 15 Nov 2005 13:03:44 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?

I don't think we will be recreating the chains on every invocation.
It'll go like this:

1) User gets to configure a per session manager chain. Created once per
session manager (if used) using builder approach
2) User gets to configure a per port chain. Created once per port (if
used) using builder approach
3) User gets to configure a per session (connection) chain. Created once
per session (if used) using builder approach

When a new session is created, the chains (1) (2) (3) which apply to the
connection are tied together in to a "ConnectionChain" (behind the
scnenes - not visible to the user) by the mechanisms discussed in my
recent posts. Individual filters are not cloned or recreated to achieve
this.
The user never sees the ConnectionChain.

Each filter call for a connection is simply a call in to the connection
chain.

Does this address your concerns?

Thanks,

Dave
 

-----Original Message-----
From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com] 
Sent: 15 November 2005 12:50
To: Apache Directory Developers List
Subject: RE: [mina] IoFilters: DIRMINA-121 / 122

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



This e-mail and any attachment is for authorised use by the intended recipient(s) only. It
may contain proprietary material, confidential information and/or be subject to legal privilege.
It should not be copied, disclosed to, retained or used by, any other party. If you are not
an intended recipient then please promptly delete this e-mail and any attachment and all copies
and inform the sender. Thank you.

Mime
View raw message