directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: [jira] Commented: (DIRMINA-121) Per-port filter chain
Date Thu, 17 Nov 2005 11:29:40 GMT
 

 

________________________________

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

 


Mime
View raw message