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 implementation. 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 [mailto:[EMAIL PROTECTED] > 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 cached > 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. What > 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 furher. > > Hopefully we'll now be able to agree that we are not in "la-la land" and > 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 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.
