directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Remove [Mutable]InterceptorConfiguration for 1.5.1? Also some thread-safety concerns
Date Sat, 18 Aug 2007 16:58:56 GMT
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