[ApacheDS] Cost of interceptors

[Alex Karasulu <ak...@apache.org>]

Hi Emmanuel,

Enrique is adding 2-3 new interceptors into the core.  I guess they could be
conditionally added in the configuration based on the presence of the
kerberos service or whatever service needed them.  Hmmm me thinks this is a
good example of how services can use the add/remove capabilities on the
interceptor chain.  Regardless I was wondering what the costs are on going
through these interceptor call chains.  I remember you did some metrics
around this and found that it does not cost much at all.

Alex

Re: [ApacheDS] Cost of interceptors

[Enrique Rodriguez <en...@gmail.com>]

On 5/27/07, Emmanuel Lecharny <el...@apache.org> wrote:
> ...
> However, if there are costly operations occuring in those interceptors,
> then this is another story...
>
> Which interceptors will be added ?

PasswordPolicyService - no deps outside core, engages on password add/mod.
KeyDerivationService - deps on kerberos-shared, engages on password add/mod.
KeyExportService - deps on kerberos-shared, engages on key export from DIT.

These interceptors only engage when passwords are set/reset or when a
Kerberos Key is exported from the DIT.  For password changes you can
imagine the frequency of interception and key export is relatively
rare, basically when machine credentials must be provisioned to a new
service, like a newly installed LDAP server.

I should mention I have a 4th interceptor in the works, that I'm
currently calling the "CatalogService."  The CatalogService will
support multi-realm for LDAP SASL DIGEST-MD5 and GSSAPI, Change
Password, and Kerberos (and someday multi-zone for DNS, subnets for
DHCP, etc).

Enrique

Re: [ApacheDS] Cost of interceptors

[Emmanuel Lecharny <el...@apache.org>]

Alex Karasulu a écrit :

> Hi Emmanuel,
>
> Enrique is adding 2-3 new interceptors into the core.  I guess they 
> could be
> conditionally added in the configuration based on the presence of the
> kerberos service or whatever service needed them.  Hmmm me thinks this 
> is a
> good example of how services can use the add/remove capabilities on the
> interceptor chain.  Regardless I was wondering what the costs are on 
> going
> through these interceptor call chains.  I remember you did some metrics
> around this and found that it does not cost much at all.
>
> Alex
>
Alex,

interceptors by themselves does not cost a lot. I would say that the 
ratio proce/functionalities is perfectly acceptable. Being able to add 
new interceptors is such a great advantage that we must be ready to pay 
a small price for it.

I would say that the global interceptor price is around 1.5% of the 
whole time spent into the server, during a search operation, if you 
exclude the cost of interceptor's operations (I mean, if the 
interceptors where just empty, the cost would be 1.5%).

However, if there are costly operations occuring in those interceptors, 
then this is another story...

Which interceptors will be added ?

Emmanuel

Re: [ApacheDS] Cost of interceptors

[Alex Karasulu <ak...@apache.org>]

On 5/29/07, Emmanuel Lecharny <el...@apache.org> wrote:
>
> Trustin Lee a écrit :
>
> > Hi Ersin,
> >
> > On 5/28/07, Ersin Er <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

Re: [ApacheDS] Cost of interceptors

[Marc Boorshtein <mb...@gmail.com>]

All,

I've been reading this discussion and as MyVD uses a very similar
model I thought I'd throw in my 2 cents....

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

This is exactly how MyVD works.  There is a Chain mechanism with a
different chain implementation for each operation.  While this did
lead to some minor code duplication I'm sure I could engineer that
out.  The tradeoff however is a much simpler model for the inserts (or
in apacheds' case interceptors).


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

Again, this is exactly how MyVD's insert chain works.  In point of
fact an insert has absolutely no idea what the next point in the chain
is (at least by default).  This makes it easier to implement inserts
as it allows for the creation of more generalized inserts.  For
instance MyVD has both global inserts (which are executed before the
router) and local inserts (configured for individual namespaces).  A
single insert can run in either context because the chain is the state
machine.

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

Well, I don't know if "better" is the correct word but it has
certainly worked well thus far.  You still have the debugging issues
(I tend to make liberal use of a dump transactions plugin rather then
debugging for the reasons cited in the above thread).

OK, maybe 10 cents worth of info....

Marc

Re: [ApacheDS] Cost of interceptors

[Ersin Er <er...@gmail.com>]

On 5/29/07, Emmanuel Lecharny <el...@apache.org> wrote:
> Trustin Lee a écrit :
>
> > Hi Ersin,
> >
> > On 5/28/07, Ersin Er <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...
>
> - 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
> paths...

Why not building a prototype?

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


-- 
Ersin

Re: [ApacheDS] Cost of interceptors

[Emmanuel Lecharny <el...@apache.org>]

Trustin Lee a écrit :

> Hi Ersin,
>
> On 5/28/07, Ersin Er <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...

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

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

Re: [ApacheDS] Cost of interceptors

[Trustin Lee <tr...@gmail.com>]

Hi Ersin,

On 5/28/07, Ersin Er <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
-- 
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6

Re: [ApacheDS] Cost of interceptors

[Alex Karasulu <ak...@apache.org>]

This is a great idea.  It would help simplify some things and consolidate
like
services which can shared common information.  Also we woud gain some
performance advantage.  Can you file a JIRA for this as task to perform?

We can take care of this when refactoring the core.

Alex

On 5/28/07, Ersin Er <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.
>
> On 5/28/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Hi Ersin,
> >
> > can you elaborate a little bit ? It seems that what you propose is a
> > kind of state machine which executes interceptors sequencially,
> > compared to the actual chaining.
> >
> > Thanks !
> >
> > On 5/28/07, Ersin Er <er...@gmail.com> wrote:
> > > Hi,
> > >
> > > I recommend to implement a new base interceptor which can execute
> > > multiple interceptors inside itself. If I am not wrong, Spring
> > > framework uses this scheme for Servlet filters. They have a filter
> > > implementation which can run multiple interceptors sharing same some
> > > common context. This scheme may have various advantages. If for
> > > example Kerberos service is disabled only one interceptors needs to
> > > check the service status and other interceptors need not even wake up.
> > > It also groups common services which do not make sense individually
> > > into one common place.
> > >
> > >
> > > On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
> > > > Hi Emmanuel,
> > > >
> > > > Enrique is adding 2-3 new interceptors into the core.  I guess they
> could be
> > > > conditionally added in the configuration based on the presence of
> the
> > > > kerberos service or whatever service needed them.  Hmmm me thinks
> this is a
> > > > good example of how services can use the add/remove capabilities on
> the
> > > > interceptor chain.  Regardless I was wondering what the costs are on
> going
> > > > through these interceptor call chains.  I remember you did some
> metrics
> > > > around this and found that it does not cost much at all.
> > > >
> > > > Alex
> > > >
> > > >
> > >
> > >
> > > --
> > > Ersin
> > >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
>
> --
> Ersin
>

Re: [ApacheDS] Cost of interceptors

[Ersin Er <er...@gmail.com>]

I could just said the Composite Pattern :-)

On 5/28/07, Ersin Er <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.
>
> On 5/28/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> > Hi Ersin,
> >
> > can you elaborate a little bit ? It seems that what you propose is a
> > kind of state machine which executes interceptors sequencially,
> > compared to the actual chaining.
> >
> > Thanks !
> >
> > On 5/28/07, Ersin Er <er...@gmail.com> wrote:
> > > Hi,
> > >
> > > I recommend to implement a new base interceptor which can execute
> > > multiple interceptors inside itself. If I am not wrong, Spring
> > > framework uses this scheme for Servlet filters. They have a filter
> > > implementation which can run multiple interceptors sharing same some
> > > common context. This scheme may have various advantages. If for
> > > example Kerberos service is disabled only one interceptors needs to
> > > check the service status and other interceptors need not even wake up.
> > > It also groups common services which do not make sense individually
> > > into one common place.
> > >
> > >
> > > On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
> > > > Hi Emmanuel,
> > > >
> > > > Enrique is adding 2-3 new interceptors into the core.  I guess they could be
> > > > conditionally added in the configuration based on the presence of the
> > > > kerberos service or whatever service needed them.  Hmmm me thinks this is a
> > > > good example of how services can use the add/remove capabilities on the
> > > > interceptor chain.  Regardless I was wondering what the costs are on going
> > > > through these interceptor call chains.  I remember you did some metrics
> > > > around this and found that it does not cost much at all.
> > > >
> > > > Alex
> > > >
> > > >
> > >
> > >
> > > --
> > > Ersin
> > >
> >
> >
> > --
> > Regards,
> > Cordialement,
> > Emmanuel Lécharny
> > www.iktek.com
> >
>
>
> --
> Ersin
>


-- 
Ersin

Re: [ApacheDS] Cost of interceptors

[Ersin Er <er...@gmail.com>]

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.

On 5/28/07, Emmanuel Lecharny <el...@gmail.com> wrote:
> Hi Ersin,
>
> can you elaborate a little bit ? It seems that what you propose is a
> kind of state machine which executes interceptors sequencially,
> compared to the actual chaining.
>
> Thanks !
>
> On 5/28/07, Ersin Er <er...@gmail.com> wrote:
> > Hi,
> >
> > I recommend to implement a new base interceptor which can execute
> > multiple interceptors inside itself. If I am not wrong, Spring
> > framework uses this scheme for Servlet filters. They have a filter
> > implementation which can run multiple interceptors sharing same some
> > common context. This scheme may have various advantages. If for
> > example Kerberos service is disabled only one interceptors needs to
> > check the service status and other interceptors need not even wake up.
> > It also groups common services which do not make sense individually
> > into one common place.
> >
> >
> > On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
> > > Hi Emmanuel,
> > >
> > > Enrique is adding 2-3 new interceptors into the core.  I guess they could be
> > > conditionally added in the configuration based on the presence of the
> > > kerberos service or whatever service needed them.  Hmmm me thinks this is a
> > > good example of how services can use the add/remove capabilities on the
> > > interceptor chain.  Regardless I was wondering what the costs are on going
> > > through these interceptor call chains.  I remember you did some metrics
> > > around this and found that it does not cost much at all.
> > >
> > > Alex
> > >
> > >
> >
> >
> > --
> > Ersin
> >
>
>
> --
> Regards,
> Cordialement,
> Emmanuel Lécharny
> www.iktek.com
>


-- 
Ersin

Re: [ApacheDS] Cost of interceptors

[Emmanuel Lecharny <el...@gmail.com>]

Hi Ersin,

can you elaborate a little bit ? It seems that what you propose is a
kind of state machine which executes interceptors sequencially,
compared to the actual chaining.

Thanks !

On 5/28/07, Ersin Er <er...@gmail.com> wrote:
> Hi,
>
> I recommend to implement a new base interceptor which can execute
> multiple interceptors inside itself. If I am not wrong, Spring
> framework uses this scheme for Servlet filters. They have a filter
> implementation which can run multiple interceptors sharing same some
> common context. This scheme may have various advantages. If for
> example Kerberos service is disabled only one interceptors needs to
> check the service status and other interceptors need not even wake up.
> It also groups common services which do not make sense individually
> into one common place.
>
>
> On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
> > Hi Emmanuel,
> >
> > Enrique is adding 2-3 new interceptors into the core.  I guess they could be
> > conditionally added in the configuration based on the presence of the
> > kerberos service or whatever service needed them.  Hmmm me thinks this is a
> > good example of how services can use the add/remove capabilities on the
> > interceptor chain.  Regardless I was wondering what the costs are on going
> > through these interceptor call chains.  I remember you did some metrics
> > around this and found that it does not cost much at all.
> >
> > Alex
> >
> >
>
>
> --
> Ersin
>


-- 
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com

Re: [ApacheDS] Cost of interceptors

[Ersin Er <er...@gmail.com>]

Hi,

I recommend to implement a new base interceptor which can execute
multiple interceptors inside itself. If I am not wrong, Spring
framework uses this scheme for Servlet filters. They have a filter
implementation which can run multiple interceptors sharing same some
common context. This scheme may have various advantages. If for
example Kerberos service is disabled only one interceptors needs to
check the service status and other interceptors need not even wake up.
It also groups common services which do not make sense individually
into one common place.


On 5/28/07, Alex Karasulu <ak...@apache.org> wrote:
> Hi Emmanuel,
>
> Enrique is adding 2-3 new interceptors into the core.  I guess they could be
> conditionally added in the configuration based on the presence of the
> kerberos service or whatever service needed them.  Hmmm me thinks this is a
> good example of how services can use the add/remove capabilities on the
> interceptor chain.  Regardless I was wondering what the costs are on going
> through these interceptor call chains.  I remember you did some metrics
> around this and found that it does not cost much at all.
>
> Alex
>
>


-- 
Ersin