Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 38408 invoked from network); 15 Nov 2005 12:37:20 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 15 Nov 2005 12:37:20 -0000 Received: (qmail 68760 invoked by uid 500); 15 Nov 2005 12:37:19 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 68695 invoked by uid 500); 15 Nov 2005 12:37:18 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 68684 invoked by uid 99); 15 Nov 2005 12:37:18 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2005 04:37:18 -0800 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_HELO_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [217.79.216.190] (HELO rly14e.srv.mailcontrol.com) (217.79.216.190) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Nov 2005 04:37:09 -0800 Received: from c1-ex001.groupinfra.com ([213.86.115.108]) by rly14e.srv.mailcontrol.com (MailControl) with ESMTP id jAFCakYn019950 for ; Tue, 15 Nov 2005 12:36:54 GMT Received: from uk-ex003.groupinfra.com ([158.234.38.247]) by c1-ex001.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 12:36:14 +0000 Received: from uk-ex001.groupinfra.com ([158.234.68.229]) by uk-ex003.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Nov 2005 12:36:08 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5E9E1.28FA8C1D" Subject: RE: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122) Date: Tue, 15 Nov 2005 12:36:11 -0000 Message-ID: <75CFC296F70A08409390004F30EF9B8506968400@uk-ex001.groupinfra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122) Thread-Index: AcXp3r+92qbsYCM+QeqKCsbyHmgiqwAADSqg From: "Irving, Dave" To: "Apache Directory Developers List" X-OriginalArrivalTime: 15 Nov 2005 12:36:08.0591 (UTC) FILETIME=[274899F0:01C5E9E1] X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.69.0.124 X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. ------_=_NextPart_001_01C5E9E1.28FA8C1D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Trustin, =20 Im really sorry if anything I said came accross like I was critisising the current implementation. I certainly didn't mean it do :o) I was simply searching for a clean way to enable 121 and 122 to get solved in a clean way - and it seemed that refactoring the existing chain mechanics might be a reasonable way to do that. Thanks for your comments - I'll try and address them here: =20 > I started to like your suggestion, and I'd like to see its realization. :) =20 I'll start working on it in earnest :o) Hopefully I'll be able to report back with a patch in the next few days. =20 >> When the last filter of a sub-chain is invoked, ConnectionChains does a=20 >> ( O(1) ) look up for the correct ConnectionChain based on session and >> delegates. =20 > Good idea. Perhaps we can use session attributes here?=20 =20 Session attributes are definately the best way to go here. It means we dont need to hold a mapping within ConnectionChains - and we dont need additional syncronization. I hadn't yet thought about how I'd implement the mapping efficiently - so this suggestion is really very very useful to me. Thanks!!! =20 > BTW J-F once asked us about emitting an event virtually (not a real I/O event but fabricated one).=20=20 > I guess we can support this in our ConnectionChain by exposing event emitting methods like I did in AbstractIoFilterChain?=20 Sure!=20 =20 Have an IoEventProcessor interface or some-such. The ConnectionChains (or whatever) can implement this ( - to kick off traversal like AbstractIoFilterChain does). This can then be exposed to the user (without having to expose the connection chain - which would be dangerous for obvious reasons). =20 E.g: IoEventProcessor processor =3D somthing.getEventProcessor(); processor.messageReceived(session, message);=20 =20 Viola - virtual Io events propogating right through the correct connection chain :o) =20 Dave =20 ________________________________ From: Trustin Lee [mailto:trustin@gmail.com]=20 Sent: 15 November 2005 12:18 To: Apache Directory Developers List Subject: Re: [mina] Refactoring MINA IoFilterChain (Was: IoFilters: DIRMINA-121 / 122) Hi Dave, I started to like your suggestion, and I'd like to see its realization. :) 2005/11/15, Irving, Dave :=20 So why don't we just dispatch based on IoSession?? =09 I.e, we have something like a "ConnectionChains" class which holds all=20 chains - mapped against IoSessions. The final filter of a sub-chain (sessionManager chain, port chain, session chain) is set by ConnectionChains to some private inner class. When the last filter of a sub-chain is invoked, ConnectionChains does a=20 ( O(1) ) look up for the correct ConnectionChain based on session and delegates. Good idea. Perhaps we can use session attributes here?=20 This allows us to get all the benefits previously discussed and solves the NextFilter problem (including completely asyncronous calls to NextFilter) without requiring cloning (which could be costly for some filters).=20 =09 How does that sound? Sounds cool. BTW J-F once asked us about emitting an event virtually (not a real I/O event but fabricated one). I guess we can support this in our ConnectionChain by exposing event emitting methods like I did in AbstractIoFilterChain?=20 Cheers, Trustin --=20 what we call human nature is actually human habit -- http://gleamynode.net/=20 This e-mail and any attachment is for authorised use by the intended recipi= ent(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 recipien= t then please promptly delete this e-mail and any attachment and all copies= and inform the sender. Thank you. ------_=_NextPart_001_01C5E9E1.28FA8C1D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Hi Trustin,
 
Im really sorry if anything I said came accross li= ke I was=20 critisising the current implementation. I certainly didn't mean it do=20 :o)
I was simply searching for a clean way to enable 1= 21 and=20 122 to get solved in a clean way - and it seemed that refactoring the exist= ing=20 chain mechanics might be a reasonable way to do that.
Thanks for your comments - I'll try and address th= em=20 here:
 
> I=20 started to like your suggestion, and I'd like to see its realization.=20 :)
 <= /DIV>
I'll start working on it in earnest :o) Hopefully = I'll be=20 able to report back with a patch in the next few days.
 
>> When = the last=20 filter of a sub-chain is invoked, ConnectionChains does a
>> ( O(1) ) look up for the correct=20 ConnectionChain based on session and
>> delegates.
 <= /DIV>
> Good=20 idea.  Perhaps we can use session attributes here?=20
 <= /DIV>
Session attributes are definately the best way to = go here.=20 It means we dont need to hold a mapping within ConnectionChains - and we do= nt=20 need additional syncronization. I hadn't yet thought about how I'd implemen= t the=20 mapping efficiently - so this suggestion is really very very useful to me.= =20 Thanks!!!
 
> BTW J-F once asked us about emitting an event= =20 virtually (not a real I/O event but fabricated one). =20
> I guess we can support this in our ConnectionCh= ain by=20 exposing event emitting methods like I did in AbstractIoFilterChain?=20
Sure!
 
Have an IoEventProcessor=20 interface or some-such. The ConnectionChains (or whatever) can implement th= is (=20 - to kick off traversal like AbstractIoFilterChain does).
This can then be exposed to the user (without havi= ng to=20 expose the connection chain - which would be dangerous for obvious=20 reasons).
 
E.g:
  IoEventProcessor processor =3D=20 somthing.getEventProcessor();
  processor.messageReceived(session, message);=20
 
Viola - virtual Io events propogating right throug= h the=20 correct connection chain :o)
 
Dave
 

From: Trustin Lee [mailto:trustin@gmail= .com]=20
Sent: 15 November 2005 12:18
To: Apache Directory=20 Developers List
Subject: Re: [mina] Refactoring MINA IoFilterChai= n=20 (Was: IoFilters: DIRMINA-121 / 122)

Hi Dave,

I started to like your suggestion, and I'd like = to=20 see its realization. :)

2005/11/15, Irving, Dave <dave.irving@logicacmg.com=20 >:
So=20 why don't we just dispatch based on IoSession??

I.e, we have somet= hing=20 like a "ConnectionChains" class which holds all
chains - mapped again= st=20 IoSessions.
The final filter of a sub-chain (sessionManager chain, por= t=20 chain,
session chain) is set by ConnectionChains to some private inner= =20 class.
When the last filter of a sub-chain is invoked, ConnectionChain= s=20 does a
( O(1) ) look up for the correct ConnectionChain based on sess= ion=20 and
delegates.

Good idea.  Perhaps we can use session attributes here?=20

This=20 allows us to get all the benefits previously discussed and solves
the= =20 NextFilter problem (including completely asyncronous calls to
NextFilt= er)=20 without requiring cloning (which could be costly for some
filters).=20

How does that sound?

Sounds cool.

BTW J-F once asked us about emitting an event= =20 virtually (not a real I/O event but fabricated one).  I guess we can= =20 support this in our ConnectionChain by exposing event emitting methods like= I=20 did in AbstractIoFilterChain?

Cheers,
Trustin
--
= what=20 we call human nature is actually human habit
--
http://gleamynode.net/

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 subje= ct to legal privilege. It should not be copied, disclosed to, retained or u= sed by, any other party. If you are not an intended recipient then please p= romptly delete this e-mail and any attachment and all copies and inform the= sender. Thank you.

------_=_NextPart_001_01C5E9E1.28FA8C1D--