Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 7587 invoked from network); 17 Nov 2005 11:33:19 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 17 Nov 2005 11:33:19 -0000 Received: (qmail 7669 invoked by uid 500); 17 Nov 2005 11:33:17 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 7627 invoked by uid 500); 17 Nov 2005 11:33:17 -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 7616 invoked by uid 99); 17 Nov 2005 11:33:17 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 03:33:17 -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 rly20e.srv.mailcontrol.com) (217.79.216.190) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 17 Nov 2005 03:34:50 -0800 Received: from c1-ex002.groupinfra.com ([213.86.115.109]) by rly20e.srv.mailcontrol.com (MailControl) with ESMTP id jAHBVieO028127 for ; Thu, 17 Nov 2005 11:32:53 GMT Received: from uk-ex003.groupinfra.com ([158.234.38.247]) by c1-ex002.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 11:32:52 +0000 Received: from uk-ex001.groupinfra.com ([158.234.68.229]) by uk-ex003.groupinfra.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 17 Nov 2005 11:32:49 +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_01C5EB6A.9BAA850D" Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain Date: Thu, 17 Nov 2005 11:32:36 -0000 Message-ID: <75CFC296F70A08409390004F30EF9B8506968415@uk-ex001.groupinfra.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [jira] Commented: (DIRMINA-121) Per-port filter chain Thread-Index: AcXrOGNDH66+gEZUQqy44JIwb2p+oAAL3hWwAACpqgA= From: "Irving, Dave" To: "Apache Directory Developers List" X-OriginalArrivalTime: 17 Nov 2005 11:32:49.0331 (UTC) FILETIME=[A3930830:01C5EB6A] X-Scanned-By: MailControl A-05-40-01 (www.mailcontrol.com) on 10.69.0.130 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_01C5EB6A.9BAA850D Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Jose, =20 Check out my "smart-NextFilter" proposal. I dont think its complicated and keeps the filter stuff unchanged from a users perspective (and it gives you complete filter control). I think thats a 3rd option to add to your list below :o) =20 Dave ________________________________ From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]=20 Sent: 17 November 2005 11:30 To: Apache Directory Developers List Subject: RE: [jira] Commented: (DIRMINA-121) Per-port filter chain =20 =20 ________________________________ From: Trustin Lee [mailto:trustin@gmail.com]=20 Sent: 17 November 2005 05:33 To: Apache Directory Developers List Subject: Re: [jira] Commented: (DIRMINA-121) Per-port filter chain =20 2005/11/17, Trustin Lee : This is a great example that makes us reconsider chain copying. To resolve this we must have only one chain per session, and per-acceptor chain and per-port chain should be added to the per-session chain just before sessionCreated is invoked. It's a little bit overhead, but I think it is fine if we implement it very effectively. Perhaps per-port and per-acceptor chains could be implemented as an array list and used only as a configuration. WDYT?=20 This approach will give a performance penalt if we're going to add a filter to multiple sessions. The question is if we can afford it. The alternative today is to create the entire chain on each session, which is even more expensive. This is why I have proposed some sort of lazy copying of the chain, which means that you only pay the price if you need to (if you actually modify your chain on a session). Per-acceptor (if we still keep it) and per-port can be added together during port binding (as this is a one time of operation). =20 The only issue left is that NextFilters are not safe anymore to remember for the entire lifecycle of the Filter. I see two possible solutions here: =20 1) Tell people it is not safe to remember and if you do it is at your own risk. You can always obtain the NextFilter from the session. 2) Add a IoFilter.chainRelocated(NextFilter old, NextFilter new) method to be called in the filter in the case of a copy. So any filter that caches will be notified of the change and do whatever is necessary. =20 I do not like (2) as I do not think we should encourage caching, but it may solve the problem easily. =20 Jose Alberto =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_01C5EB6A.9BAA850D Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable
Jose,
 
Check out my "smart-NextFilter" proposal. I dont t= hink its=20 complicated and keeps the filter stuff unchanged from a users perspective (= and=20 it gives you complete filter control).
I think thats a 3rd option to add to your list bel= ow=20 :o)
 
Dave

From: Jose Alberto Fernandez=20 [mailto:jalberto@cellectivity.com]
Sent: 17 November 2005=20 11:30
To: Apache Directory Developers List
Subject: RE:= =20 [jira] Commented: (DIRMINA-121) Per-port filter chain

 

 

From: Trustin Lee=20 [mailto:trustin@gmail.com]
Sent: 17 November 2005 05:33
<= SPAN=20 style=3D"FONT-WEIGHT: bold">To: Apac= he=20 Directory Developers List
Subject: Re: [jira] Commented:=20 (DIRMINA-121) Per-port filter chain

 

2005/11/17, Trustin Lee <trustin@gmail.com>:<= /SPAN>

This is a great example that makes us reconsider = chain=20 copying.  To resolve this we must have only one chain per session, and= =20 per-acceptor chain and per-port chain should be added to the per-session ch= ain=20 just before sessionCreated is invoked.  It's a little bit overhead, bu= t I=20 think it is fine if we implement it very effectively.  Perhaps per-por= t and=20 per-acceptor chains could be implemented as an array list and used only as = a=20 configuration.  WDYT?


This approach will give a performance penalt = if=20 we're going to add a filter to multiple sessions.  The question is if = we=20 can afford it.

The alternative = today=20 is to create the entire chain on each session, which is even more expensive= .=20 This is why I have proposed some sort of lazy copying of the chain, which m= eans=20 that you only pay the price if you need to (if you actually modify your cha= in on=20 a session). Per-acceptor (if we still keep it) and per-port can be added=20 together during port binding (as this is a one time of=20 operation).

 

The only issue l= eft is=20 that NextFilters are not safe anymore to remember for the entire lifecycle = of=20 the Filter. I see two possible solutions here:

 

<= ![if !supportLists]>1)  =20 T= ell=20 people it is not safe to remember and if you do it is at your own risk. You= can=20 always obtain the NextFilter from the session.

<= ![if !supportLists]>2)  =20 A= dd a=20 IoFilter.chainRelocated(NextFilter old, NextFilter new) method to be called= in=20 the filter in the case of a copy. So any filter that caches will be notifie= d of=20 the change and do whatever is necessary.

 

I do not like (2= ) as I=20 do not think we should encourage caching, but it may solve the problem=20 easily.

 

Jose=20 Alberto

<= SPAN=20 style=3D"FONT-SIZE: 12pt; COLOR: navy"> 

<= /DIV>


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_01C5EB6A.9BAA850D--