directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: [ApacheDS] Cost of interceptors
Date Tue, 29 May 2007 10:23:26 GMT
On 5/29/07, Emmanuel Lecharny <elecharny@apache.org> wrote:
>
> Trustin Lee a écrit :
>
> > Hi Ersin,
> >
> > On 5/28/07, Ersin Er <ersin.er@gmail.com> 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...


Debugging can be a bitch but you learn certain tricks
to prevent the large stack from taking too much time ... just like with
Maven.  Really you need
to know where to set the breakpoint (which interceptor) and you can handle
debugging better
but still debugging is a PITA I agree.  However the tools exist to lessen
the burden although not
completely irradicate it.  How do you think I have survived so long without
loosing all my hair :)?

- 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 !


Only if the cost of this is not high :).

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


Does this become the CoR pattern?

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


You're right but man I would not want to model this as a statemachine
explicitly.  This current
configuration makes life a lot easier.

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.


Sure it can be but we don't have good options right now.  I think we will
see better
options as we clean up the core with refactoring and also as well add more
critical features.   I think any changes now might be premature.  The best
thing
to do is to collect these ideas and then sit down to pump out a feature
release that
refactors and incorporates these ideas.  We might want a wiki page to
capture these
ideas with a general task in JIRA that points to it and says we just need to
look out
for a better mechanism here.

I think one of us will figure this out while in the shower or on the way
from work :).

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


Hahaha yeah I think you're biased by I love you for it :).  We need more
old farts they've seen more than others and obviously from the term can
hold back less :-D.

, 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
> paths...


This is a good start.  Trustin and Ersin have had some good ideas.  Let's
keep track
of them and make sure we add to it.

Emmanuel
> 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
> bad...


+1

Alex

Mime
View raw message