directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <akaras...@apache.org>
Subject Re: Remove [Mutable]InterceptorConfiguration for 1.5.1? Also some thread-safety concerns
Date Sat, 18 Aug 2007 19:14:20 GMT
I glad to see you involved and thinking about these issues and aspects
of the server David.  I know we're going to gain a lot from your knowledge
in these areas.

With respect to the Spring discussions I think we hit a stalemate a few
weeks back.  I know I've spoken to both you and Chris about this who feel
Spring can do much of what we would like to do.  As you know my stance
is to avoid being dependent on Spring.

However I think we have some idea of how we can remain container independent
while still leveraging Spring.  We still need some discussions on this but I
don't
think they're going to happen in the next 3 days.

Keep in mind 1.5.1 is a feature release where we're just releasing to get
feature
regardless of stability into the hands of our users.  We can release at any
point
in time again thereafter so don't feel pressured to pump your changes into
this
release.

Alex

On 8/18/07, David Jencks <david_jencks@yahoo.com> wrote:
>
> A while back there was some discussion about just how much container
> functionality apacheds needs to duplicate for spring, and IIUC there
> was general agreement that [Mutable]InterceptorConfiguration could be
> replaced by just letting the container create the interceptors directly.
>
> I started looking at this issue this morning and think it would be
> pretty easy to fix so I'm wondering if there's any chance it could
> get into 1.5.1.
>
> I also see what looks to me like double-checked-locking problems with
> InterceptorChain setting up the chain of Entry objects.  IIUC there
> are a bunch of methods to insert,remove, etc interceptors in the
> running server but the actual code that traverses the interceptor
> chain is not at all synchronized.  This is a double-checked-locking
> scenario and can lead to the live interceptor chain using
> incompletely initialized interceptor objects.  The usual fix nowadays
> for such problems is to make the variables pointing to the possibly
> incompletely initialized objects volatile.  IIUC this would be the
> InterceptorChain.Entry prevEntry and nextEntry fields.
>
> AFAICT the runtime change-the-chain methods are not called in the
> apacheds code base at the moment, so I think an acceptable
> alternative would be to remove those methods and rely on no one
> starting to use the server until it's fully initialized.  This would
> involve removing the InterceptorChain addFirst, addLast, addBefore,
> addAfter methods.
>
>
> OK... back to the how-much-extra-wrapping question.
>
> I haven't started to code yet but I think the best solution for now
> will be to:
>
> - In each interceptor class that actually uses an interceptor
> configuration, replace that with individual attributes (I think only
> the replication interceptor has any attributes at the moment)
> - remove the InterceptorConfiguration cfg argument from Interceptor.init
>
> At this point we won't need InterceptorConfiguration any more, the
> container (spring) can create the interceptors itself, and
> InterceptorChain will get a list of interceptors it needs to
> initialize rather than a list of InterceptorConfigurations.
>
> thanks
> david jencks
>
>
>
>

Mime
View raw message