directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Irving, Dave" <dave.irv...@logicacmg.com>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 11:32:36 GMT
Jose,
 
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)
 
Dave

________________________________

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



 

 

________________________________

From: Trustin Lee [mailto:trustin@gmail.com] 
Sent: 17 November 2005 05:33
To: Apache Directory Developers List
Subject: Re: [jira] Commented: (DIRMINA-121) Per-port filter chain

 

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

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? 


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).

 

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:

 

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.

 

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

 

Jose Alberto

 



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.

Mime
View raw message