> 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > 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.
