directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel Lecharny <>
Subject Re: [ApacheDS] Cost of interceptors
Date Tue, 29 May 2007 06:14:59 GMT
Trustin Lee a écrit :

> Hi Ersin,
> On 5/28/07, Ersin Er <> wrote:
>> Well, I am talking about an interceptor chain in a chain.
>> Int1 -> Int2 -> Int3(Int3.1 -> Int3.2 -> Int3.3) -> Int4 - > Int5
>> If Int3 is enabled all Int3.x will be executed. If Int3 is disabled,
>> the executed will just be forwarded to Int4, not Int3.1. This is
>> because the Kerberos service can be enabled or disabled at all. BTW,
>> if Kerberos service is enabled and it's desired to disable a
>> subservice of it, it's still possible. Int3.x can only know about
>> other Int3.x if needed. Int3 is a blackbox, it is just a regular
>> interceptor to the outer world. It has a registration mechanism, as
>> just Interceptors have, which can again register Interceptor. Well, I
>> think Int3 implements two interfaces: InterceptorChain and
>> Interceptor.
> We need to ask ourselves before providing such a composite
> interceptor; Is each element of the composite interceptor useful
> independently?  If not, why do we need to implement each sub-logic as
> an interceptor?  Can't we just implement it as a POJO and use it as a
> utility from an interceptor that assembles the sub logic?  Adding a
> composite interceptor feature will cause complexity to the interceptor
> architecture so we need to be careful.  Of course, adding it is not a
> problem at all once we have a concrete use case.
> Trustin

Hi guys,

I must say that Ersin idea is quite natural, but that Trustin objections 
are also acceptable. What I wanted to add is that we have issues with 
the current pattern and I would like to start thinking about solutions 
to those issues. Here they are :

- the Interceptors are supposely dynamic, but even if the addBefore and 
addAfter methods are synchronized, the code itself is not threadsafe 
(it's ok to protect method, but as we don't protect access to the get() 
metho to, this is useless. It would be better to protect the hashmap.)

- debugging an interceptor chain is a nightmare : as we don't know 
explicitely which is the next interceptor, we have to step to a *lot* of 
classes, to end with a stack which has sometime more than one hundred 
method calls...

- btw, each method which is not void *must* logs something, like 
"entering this interceptor" and "returning from this interceptor". It 
would have helped me a lot, avoiding never ending debug sessions... Log 
log log !

- as each method in an interceptor should know which is the next 
interceptor to call for the same method, this leads to some mi of 
concept : we are dealing with a chain of global interceptors into which 
each motho has its own path. At this point I just wonder if it would not 
be better to define a add() interceptorChain, delete() interceptorChain, 
search() interceptorChain etc.

- I'm not sure that a method should know which interceptor it must call. 
I think it would be better to see this interceptor chain as a state 
machine, with calculated transitions. Adopting this vision will allow a 
lighter system, where pre and post conditions would be run partly on the 
engine (the transition selector) and partly in the next state. In fact, 
we will have two kinds of pre and post conditions : selectors pre/post 
productions, and applicatives pre/post treatment.

Ok, I want to be honest, I'm not sure I see a better solution than the 
one we actually have, which works pretty well, but I *feel* that it 
could be done better. May be I'm totally wrong, may be is just because 
I'm an old fart and pretty much biased toward state machines - old 
school computer science :) -, I don't know. I just wanted to open a 
thread on this subject, but, please, *no flame* ! I don't think there is 
an ultimate solution, I would just like to see if we have explored other 

PS : this is all but urgent. Not a big deal if we decide to refactor - 
or not - this pattern in 6 months or in 2 years. As this is the heart of 
ApacheDS (which has many hearts;), it's better to think twice than doing 

View raw message