directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 12:26:29 GMT
My only point here is that caching NextFilter per se is useless.
I originally thought we were caching NextFilter because we will not have
a seesion to obtain it from. (That was my lala-land).

But that is not the case. You will always need to cache the session or
sessions that you want to send your asynchronous event to. And if you
have the session, then you can obtain NextFilter with the current API of
MINA. So there is no need to chache NextFilter and hence there is no
need for having something other than a simple FilterChain

You can still write your filter below without needing to cache
NextFilter. Am I wrong?

This is all I was trying to enphasize. ;-)

Jose Alberto

> -----Original Message-----
> From: Irving, Dave []
> Sent: 17 November 2005 12:02
> To: Apache Directory Developers List
> Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
> > Ok, can someone explain to me, how can a filter propagate an event
> > asynchronously (I presume to all the sessions using it) without
> knowing
> > what those sessions are? How can a filter make one call in its
> NextFilter
> > and the message be received by ALL the sessions sharing that chain?
> >I think we are in lala-land here.
> I think I've explained this a few times.
> First we are not in lala-land. This is perfectly do-able. Except that
> your example isn't quite the real use case: A filter would generate an
> event for its associated session - not ** all ** sessions.
> So, lets pretend we have this set up:
> Acceptor:  ThreadPoolFilter
> Port    :  SSL, AsyncFilter
> Session :  MyFilterX
> Logically, the session chain has "ThreadPoolFilter, SSL, MyFilterX".
> At some point, AsyncFilter wants to generate an asyncronous event.
> happens?
> Well, remember that an event is always associated with a Session.
> Sessions have attributes.
> An attribute can specify the logical filter flow for the session (i.e,
> the order in which filters should currently be used for the session).
> So, first, the "real" NextFilters installed to a filter are
> smart-proxies which delegate out to the correct session flow for the
> session by looking up the flow as an attribute: Lets call this a
> "SessionChainView".
> This SessionChainView keeps the order of chains for a session, and
> manages "logical" re-ordering.
> Its actually quite simple (we have smart proxies today:
> AbstractIoFilter.Entry.NextFilter) - this just takes it one step
> Hopefully we'll now be able to agree that we are not in "la-la land"
> that this is actually do-able without impating user experience at all.
> Dave
> 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
> 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.

View raw message